This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: embedded post mortem dumps
- To: guy@netapp.com (Guy Harris)
- Subject: Re: embedded post mortem dumps
- From: jtc@redback.com (J.T. Conklin)
- Date: 07 May 1999 13:04:40 -0700
- Cc: gdb@sourceware.cygnus.com
- References: <199904302340.QAA19653@tooting.netapp.com>
- Reply-To: jtc@redback.com
>>>>> "Guy" == Guy Harris <guy@netapp.com> writes:
Guy> The panic code in our OS just spews main memory (compressed, in
Guy> later versions of our code) to special core dump regions on disk,
Guy> and, on reboot, a "savecore" command (some code of which is
Guy> lifted straight from BSD) saves it to a core dump file.
Guy> We can do that because we have disks and a file system; people
Guy> sometimes use "embedded" to mean "embedded in a tiny system", and
Guy> we're pretty far from a tiny system.
My definition for "embedded" in this context was "embedded in a system
that has enough resources to support crash dumps". It is broad enough
to include a lot of systems that I personally would consider too small
to support crash dumps efficently; but I didn't want a definition that
would preclude a system that could technically perform the task due to
my own biases.
I wouldn't call the RedBack boxes tiny, but we don't have disks or
enough flash (in an off the shelf config, there's nothing stopping
someone from putting a higher density flash card in the system) to
store a crash dump. Fortunately we do have network access, and will
be able to dump state in a reasonable time. I can't imagine doing the
same on a system that would have to dump megabytes over a serial link.
jtc> However, on the GDB side, core file support seems to be entertwined
jtc> with "native" (host == target) debugging environments.
Guy> How so?
It turns out not to be so. I jumped the gun noting that corelow.o was
in NATDEPFILES in the configs. Based on past experiences, native code
has been painfully system specific and I expected the same for core
dumps. It's been a fortunate surprise.
Guy> It wasn't hard to add a new core file format to BFD; the trickier
Guy> parts were handling things such as trap frames (which I handle
Guy> sort of like signal trampoline frames) and threads (our OS runs
Guy> everything in a single address space, and *doesn't* have separate
Guy> ".reg" sections for each process in the core dump file, so to
Guy> treat our processes as threads required beating on the thread
Guy> support stuff a bit).
For a first cut, I think I'm going ignore thread support and simply
dump memory and registers. That will give the folks here, with the
assistance of some canned user-defined functions, a big leg up. As
time goes on, I'll see how their requirements develop.
Thanks,
--jtc
--
J.T. Conklin
RedBack Networks