buildMemory assumes all Non-Anonymous VMA file mappings are to the executable, is it OK?

[hitzhangjie]

Hi, guys, I'm learning how coredump file created and how to use it for debugging.

1. when we send some signals to process, the kernel will generate the coredump for it
2. or like dlv, we can use ptrace + /proc to read the info and dump

After reading the relevant code in dlv, I found I'm confused about a little code here.

1. (*Debugger).Dump, when dump, it dumps the PT_NOTE segment, with notes of dlv header, process info, threads info, etc. There's no note.NT_FILE note here. Well we indeed process this kind of notes when do buildMemory when we run dlv core [executable] [core].
2. So I think the note.NT_FILE note maybe generated by kernel, actually the kernel indeed generate these notes.
3. the buildMemory function, the comment says "for now, assume all file mappings are to the exe",
4. and readNote function, it doesn't read the mapped file names.
5. Indeed, the mapped files maybe shared libraries, or other files rather than the executable, and because we didn't read the mapped file names here, only the VMA.start, VMA.end, VMA.offsetByPages. So I think if the coredump contains the data mapped, we don't need to read the mapped file at all.
6. I read some articles and check the test demo, for the ReadOnly VMA, the FileSZ in ProgHeaders is zero. It says the actual data isn't saved in the coredump, we should read it via the filename mapped.
7. here, https://www.gabriel.urdhr.fr/2015/05/29/core-file/#:~:text=Their%20FileSiz%20is,is%20described%20later).

So I think, is there a problem here in dlv? we ignore the mapped filename, and the data is not dumped into the core, we should read the file to get the data.

I'm a little confused here, does that means dlv, so far, not handle this? Most go programs use static linkage, maybe it's not a problem for most debugging cases. I'm write some articles and I use dlv as demo, so I want to make it clear to the readers. If I misunderstand some points, please let me know.

Thank you.

---

The following are the relevant code, and my test demo written in c programming language.

func buildMemory(core, exeELF *elf.File, exe io.ReaderAt, notes []*note) proc.MemoryReader {
	memory := &SplicedMemory{}

	// For now, assume all file mappings are to the exe.
	for _, note := range notes {
		if note.Type == _NT_FILE {
			fileNote := note.Desc.(*linuxNTFile)
			for _, entry := range fileNote.entries {
				r := &offsetReaderAt{
					reader: exe,
					offset: entry.Start - (entry.FileOfs * fileNote.PageSize),
				}
				memory.Add(r, entry.Start, entry.End-entry.Start)
			}
		}
	}

	// Load memory segments from exe and then from the core file,
	// allowing the corefile to overwrite previously loaded segments
	for _, elfFile := range []*elf.File{exeELF, core} {
		if elfFile == nil {
			continue
		}
		for _, prog := range elfFile.Progs {
			...
		}
	}
	return memory
}

// readNote reads a single note from r, decoding the descriptor if possible.
func readNote(r io.ReadSeeker, machineType elf.Machine) (*note, error) {
        ...
	case _NT_FILE:
		// No good documentation reference, but the structure is
		// simply a header, including entry count, followed by that
		// many entries, and then the file name of each entry,
		// null-delimited. Not reading the names here.
		data := &linuxNTFile{}
		if err := binary.Read(descReader, binary.LittleEndian, &data.linuxNTFileHdr); err != nil {
			return nil, fmt.Errorf("reading NT_FILE header: %v", err)
		}
		for i := 0; i < int(data.Count); i++ {
			entry := &linuxNTFileEntry{}
			if err := binary.Read(descReader, binary.LittleEndian, entry); err != nil {
				return nil, fmt.Errorf("reading NT_FILE entry %v: %v", i, err)
			}
			data.entries = append(data.entries, entry)
		}
		note.Desc = data
          ...
}

a demo with c programming language, it only prints its pid every 1s. Then I send a SIGBUS to it, and check the coredump with readelf as following:

make checkcore
Found core file at: /home/zhangjie/debugger101/tinydbg/examples/core_demo/core.pid_printer.PC-GeniusStation.1749948857.92721.7

**===> step1: checking ProgHeaders**

Elf file type is CORE (Core file)
Entry point 0x0
There are 17 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x00000000000003f8 0x0000000000000000 0x0000000000000000
                 0x0000000000000bdc 0x0000000000000000         0x0
  LOAD           0x0000000000001000 0x0000000000400000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000600000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  R      0x1000
  LOAD           0x0000000000003000 0x0000000000601000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  RW     0x1000
  LOAD           0x0000000000004000 0x0000000001ab7000 0x0000000000000000
                 0x0000000000021000 0x0000000000021000  RW     0x1000
  LOAD           0x0000000000025000 0x00007ff07c4d6000 0x0000000000000000
                 0x0000000000001000 0x00000000001cd000  R E    0x1000
  **LOAD           0x0000000000026000 0x00007ff07c6a3000 0x0000000000000000
                 0x0000000000000000 0x00000000001ff000         0x1000**
  LOAD           0x0000000000026000 0x00007ff07c8a2000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  R      0x1000
  LOAD           0x000000000002a000 0x00007ff07c8a6000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  RW     0x1000
  LOAD           0x000000000002c000 0x00007ff07c8a8000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     0x1000
  LOAD           0x0000000000030000 0x00007ff07c8ac000 0x0000000000000000
                 0x0000000000001000 0x000000000002f000  R E    0x1000
  LOAD           0x0000000000031000 0x00007ff07cad0000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  RW     0x1000
  LOAD           0x0000000000033000 0x00007ff07cadb000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  R      0x1000
  LOAD           0x0000000000034000 0x00007ff07cadc000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  RW     0x1000
  LOAD           0x0000000000036000 0x00007fff7fa1a000 0x0000000000000000
                 0x0000000000023000 0x0000000000023000  RW     0x1000
  LOAD           0x0000000000059000 0x00007fff7fba9000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  R      0x1000
  LOAD           0x000000000005d000 0x00007fff7fbad000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  R E    0x1000

**===> step2: checking notes in PT_NOTE prog**

Displaying notes found at file offset 0x000003f8 with length 0x00000bdc:
  Owner                 Data size       Description
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
  CORE                 0x00000088       NT_PRPSINFO (prpsinfo structure)
  CORE                 0x00000080       NT_SIGINFO (siginfo_t data)
  CORE                 0x00000150       NT_AUXV (auxiliary vector)
  CORE                 0x00000268       NT_FILE (mapped files)
    Page size: 4096
                 Start                 End         Page Offset
    0x0000000000400000  0x0000000000401000  0x0000000000000000
        /home/zhangjie/debugger101/tinydbg/examples/core_demo/pid_printer
    0x0000000000600000  0x0000000000601000  0x0000000000000000
        /home/zhangjie/debugger101/tinydbg/examples/core_demo/pid_printer
    0x0000000000601000  0x0000000000602000  0x0000000000000001
        /home/zhangjie/debugger101/tinydbg/examples/core_demo/pid_printer
    0x00007ff07c4d6000  0x00007ff07c6a3000  0x0000000000000000
        /usr/lib64/libc-2.28.so
    **0x00007ff07c6a3000  0x00007ff07c8a2000  0x00000000000001cd
        /usr/lib64/libc-2.28.so**
    0x00007ff07c8a2000  0x00007ff07c8a6000  0x00000000000001cc
        /usr/lib64/libc-2.28.so
    0x00007ff07c8a6000  0x00007ff07c8a8000  0x00000000000001d0
        /usr/lib64/libc-2.28.so
    0x00007ff07c8ac000  0x00007ff07c8db000  0x0000000000000000
        /usr/lib64/ld-2.28.so
    0x00007ff07cadb000  0x00007ff07cadc000  0x000000000000002f
        /usr/lib64/ld-2.28.so
    0x00007ff07cadc000  0x00007ff07cade000  0x0000000000000030
        /usr/lib64/ld-2.28.so
  CORE                 0x00000200       NT_FPREGSET (floating point registers)
  LINUX                0x00000340       NT_X86_XSTATE (x86 XSAVE extended state)
   description data: 7f 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffff80 1f 00 00 ffffffff ffffffff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff ffffffff ffffffff ffffffff 00 00 00 00 00 ffffffff ffffffff ffffffff 00 ffffffff ffffffff 00 ffffffff ffffffff ffffffff ffffffff 00 00 00 00 00 ffffffff ffffffff ffffffff 00 ffffffff ffffffff 65 74 74 69 6d 65 00 5f 5f 76 64 73 6f 5f 67 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff 00 00 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[hitzhangjie]

I think even if dlv handles this, it won't be perfect:

in buildMemory, dlv create the spliced memory for the mapped VMAs, it ignore the FileSZ==0 cases.
Even dlv record the VMAs and mapped filenames, and can read the data from filesystem, it won't be perfect.

why? The mapped files maybe readonly when process running, but after that, it could be modified on the filesytem.
So, even dlv do some more work, it won't be more useful for debugging the core. The data read maybe not the same.

So, current work of dlv is enough.

---

If I misunderstand something, please let me know.

[aarzilli]

What you wrote looks correct to me.

So I think the note.NT_FILE note maybe generated by kernel, actually the kernel indeed generate these notes.

There are several tools that generate core files. The kernel is one, gdb is another.