This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Core dump processing for vxWorks
- To: Sumit Garg <sgarg at apertonet dot com>
- Subject: Re: Core dump processing for vxWorks
- From: jtc at redback dot com (J.T. Conklin)
- Date: 26 Apr 2001 14:58:22 -0700
- Cc: "'gdb at sourceware dot cygnus dot com'" <gdb at sourceware dot cygnus dot com>
- References: <9AAAF61573C83B4CB623DE3EEA4F9DBC20BD2D@nebula.apertonet.com>
- Reply-To: jtc at redback dot com
>>>>> "Sumit" == Sumit Garg <sgarg@apertonet.com> writes:
Sumit> I am aware that GDB provides support for core file
Sumit> processing. However, I am unable to find a method to generate a
Sumit> core file for a vxWorks/i960 platform. I looked up in the
Sumit> tWdbAgent task, for providing an API to store/dume the core
Sumit> file, but was unsuccessful.
Doesn't getting a core dump via WDB imply the system is still alive?
If it's alive, you don't need a core dump because you could simply
connect to the target with the debugger.
So you need to do something else. For example, your crash handler
could jump to some standalone code, preferably in ROM, to perform the
dump. You'll have to reserve a region of memory free for the code to
use (otherwise the crash dump routine might be clobbering the very
memory contents you need to find the bug). And since the state of
the hardware may be in doubt, the crashdump code should carefully
re-initialize enough hardware so it can write a dump.
You might be able to get by with more, by having your crash dump code
as part of your program. But I think it's better to assume as little
as possible after a system crash.
--jtc
--
J.T. Conklin
RedBack Networks