This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Thread signal information
On Wed, Jul 24, 2002 at 10:28:52AM -0700, Dan Kegel wrote:
> Daniel Jacobowitz wrote:
> >On Wed, Jul 24, 2002 at 09:00:43AM -0700, Lucy Zhang wrote:
> >>I'm constructing an ELF core dump (conversion from a different formatted
> >>dump). I'm trying to add thread information by using a prstatus struct for
> >>each thread. I was wondering what should I put for the signal information
> >>for each thread. Do I even need this info for threads other than the
> >>faulting thread?
> >
> >Not really. I believe that GDB only recognizes the signal in the first
> >listed thread (or it may have been the last listed thread.... there was
> >a fix in this area recently, I believe). First listed (faulting)
> >certainly makes the most sense, and GDB definitely only cares about one
> >thread.
>
> Does one give up anything by doing a postmortem gdb session
> rather than a live session? Obviously one loses the ability to continue,
> but what else? Presumably (once we coax the OS into producing the
> proper core dump) we still can do 'info threads' and 'backtrace' on
> each thread, right?
>
> (I haven't used core dumps for a long, long time.
> Very recently, though, I used a signal handler to do just-in-time
> startup of gdbserver to help debug a program running on a 100 node
> cluster. If my nodes had hard disks, I'd be more likely to use
> coredumps :-)
>From a design perspective, in the corefiles we get each thread's
registers from the kernel; in live debugging we use thread_db.
Given Linux's one-process-one-thread model at present, this has no
practical significance.
>From a convenience perspective, as Andrew said, you lose inferior
function calls. You can't modify memory. Etc.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer