Re: Thread signal information

[Daniel Jacobowitz <drow@mvista.com>]

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