This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: gdb and shared memory
- To: Christopher Neufeld <neufeld@physics.utoronto.ca>
- Subject: Re: gdb and shared memory
- From: Jim Blandy <jimb@cygnus.com>
- Date: 27 May 1999 11:10:22 -0500
- Cc: gdb@sourceware.cygnus.com
- References: <199905251255.IAA15222@caliban.physics.utoronto.ca>
> So, I can't get at the program state saved in the core file, and I
> have to rerun the program within the debugger (that works fine, I can do
> a backtrace after the abort() gets called).
> My question, then, is this: is there a magic command I don't know
> about which informs "gdb" that I don't care if it can't get at the shared
> memory segments, the state I'm interested is in the process' unshared
> core, and I'd like to be able to backtrace and see what happened.
I don't know of any magic GDB command to do this. You might use
objdump -h to try to see which section your shared memory segment is
getting dumped in. If it gets its own section, then objcopy has a
--remove-section option that you could use to edit it out.