This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: embedded post mortem dumps


>>>>> "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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]