Re: embedded post mortem dumps

[guy@netapp.com (Guy Harris)]

We use GDB to analyze core dump files from NetApp appliances, and have
done so for a while.

> The implementation I'm imagining would have the exception handler save
> state and then jump to a dump routine that would initialize itself
> (assuming nothing about hardware state, etc.) and operate in a pre-
> defined/reserved region of memory.  It would then dump the register
> and memory contents over the network via tftp or to a flash device.

The panic code in our OS just spews main memory (compressed, in later
versions of our code) to special core dump regions on disk, and, on
reboot, a "savecore" command (some code of which is lifted straight from
BSD) saves it to a core dump file. 

We can do that because we have disks and a file system; people sometimes
use "embedded" to mean "embedded in a tiny system", and we're pretty far
from a tiny system.

But, as you note, that's the embedded-OS side; the way that's done
depends a lot on the OS....

> However, on the GDB side, core file support seems to be entertwined
> with "native" (host == target) debugging environments.

How so?  It wasn't hard to add a new core file format to BFD; the
trickier parts were handling things such as trap frames (which I handle
sort of like signal trampoline frames) and threads (our OS runs
everything in a single address space, and *doesn't* have separate ".reg"
sections for each process in the core dump file, so to treat our
processes as threads required beating on the thread support stuff a
bit).  Unfortunately, my changes are in a not-very-general-or-portable
form, involving some sleazy changes to the underlying infrastructure,
but I think some of that could be handled with infrastructure changes.