Date: Mon, 22 Nov 2021 09:47:42 -0800 From: John Baldwin <jhb@FreeBSD.org> To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@moritz.systems>, freebsd-hackers@FreeBSD.org Cc: emaste@FreeBSD.org, peter@FreeBSD.org Subject: Re: Looking for rationale for the minidump format Message-ID: <cd2f2575-db5b-db6a-db9d-1575d309a74f@FreeBSD.org> In-Reply-To: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems> References: <305082d9f216bb8382773c074eaf7a5c3101cc13.camel@moritz.systems>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd2f2575-db5b-db6a-db9d-1575d309a74f>