Re: Looking for rationale for the minidump format

On 11/21/21 6:42 AM, Michał Górny wrote:
> Hi, everyone.
> 
> As part of the work contracted by the FreeBSD Foundation, I'm working
> on adding explicit minidump support to LLDB.  When discussing
> the options with upstream, I've been asked why FreeBSD created their own
> minidump format.
> 
> I did a bit of digging but TBH all the rationale I could get was to
> create partial memory dumps.  However, unless I'm mistaken the ELF
> format is perfectly capable of that -- e.g. via creating an explicit
> segment for every continuous active region.
> 
> Does anyone happen to know what the original rationale for creating
> a custom file format was, or know where to find one?  Thanks in advance.

The direct map aliases pages mapped via kmem.  You'd be double dumping
all the data mapped into kmem, once for the direct map and once for the
non-direct mappings.

You can think of minidumps as being a dump of physical memory, whereas
an ELF core for a virtually-mapped kernel wants to dump virtual memory,
and there is the disconnect.

There are somewhat similar issues with talking to bare metal stubs that
insist on always using physical addresses (e.g. openocd talking to
RISC-V FPGA soft cores).  For that I have theorized (but not implemented)
adding a new qXfer (or the like) for physical memory and a way to
negotiate that a target only supports physical addresses as part of
qSupported and then having logic in the arch-dependent code (riscv-tdep.c
in gdb, not sure what the equivalent layer would be in lldb) to handle
translation of virtual addresses to physical before reading physical
memory (e.g. on RISC-V it would be sufficient to expose the $satp register
from the remote stub).

You could perhaps imagine something similar where you had an ELF core
with physical memory for PT_LOAD instead of virtual and a way to hint that
so that the debugger would handle all the virtual -> PA translation, but
you'd still need some home-grown notes for some of the other metadata we
pass along (like the message buffer, etc.).  Also, changing the format
doesn't help with reading existing crash dumps.

You could also perhaps depend on ELF register notes for thread state vs
enumerating threads (which might be nice), but you'd still have to
duplicate all of that logic to handle talking to remote baremetal stubs
like QEMU / bhyve where the threads exposed via the remote protocol are
vCPUs, not kernel threads, so that doesn't really save you any work in
the debugger in the end.

-- 
John Baldwin