Thread signal information

Thread signal information

[Lucy Zhang]

Hi,

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?

Thanks,
Lucy

Re: Thread signal information

[Daniel Jacobowitz]

On Wed, Jul 24, 2002 at 09:00:43AM -0700, Lucy Zhang wrote:
> Hi,
> 
> 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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Thread signal information

[Dan Kegel]

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 :-)
- Dan

Re: Thread signal information

[Andrew Cagney]

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

Main thing you loose is inferior function calls.  Often they are useful 
when it comes to displaying data.

Andrew

Re: Thread signal information

[Daniel Jacobowitz]

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

Re: Thread signal information

[Dan Kegel]

Daniel Jacobowitz wrote:
>>Does one give up anything by doing a postmortem gdb session
>>rather than a live session? 
> 
> 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.

... but it might if/when people start using NGPT instead of LinuxThreads.
I suppose I should check to see what that project plans to do about core dumps.

> From a convenience perspective, as Andrew said, you lose inferior
> function calls.  You can't modify memory.  Etc.

Thanks!
- Dan

Re: Thread signal information

[Lucy Zhang]

What are inferior function calls?

Lucy
----- Original Message -----
From: "Dan Kegel" <dkegel@ixiacom.com>
To: "Daniel Jacobowitz" <drow@mvista.com>
Cc: "Lucy Zhang" <lucyz@uclink4.berkeley.edu>; <gdb@sources.redhat.com>
Sent: Wednesday, July 24, 2002 12:53 PM
Subject: Re: Thread signal information


> Daniel Jacobowitz wrote:
> >>Does one give up anything by doing a postmortem gdb session
> >>rather than a live session?
> >
> > 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.
>
> ... but it might if/when people start using NGPT instead of LinuxThreads.
> I suppose I should check to see what that project plans to do about core
dumps.
>
> > From a convenience perspective, as Andrew said, you lose inferior
> > function calls.  You can't modify memory.  Etc.
>
> Thanks!
> - Dan
>
>

Re: Thread signal information

[Daniel Jacobowitz]

Calling functions in the live program, from the GDB prompt, while
debugging it.

On Thu, Jul 25, 2002 at 08:59:35AM -0700, Lucy Zhang wrote:
> What are inferior function calls?
> 
> Lucy
> ----- Original Message -----
> From: "Dan Kegel" <dkegel@ixiacom.com>
> To: "Daniel Jacobowitz" <drow@mvista.com>
> Cc: "Lucy Zhang" <lucyz@uclink4.berkeley.edu>; <gdb@sources.redhat.com>
> Sent: Wednesday, July 24, 2002 12:53 PM
> Subject: Re: Thread signal information
> 
> 
> > Daniel Jacobowitz wrote:
> > >>Does one give up anything by doing a postmortem gdb session
> > >>rather than a live session?
> > >
> > > 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.
> >
> > ... but it might if/when people start using NGPT instead of LinuxThreads.
> > I suppose I should check to see what that project plans to do about core
> dumps.
> >
> > > From a convenience perspective, as Andrew said, you lose inferior
> > > function calls.  You can't modify memory.  Etc.
> >
> > Thanks!
> > - Dan
> >
> >
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

how does GDB find the symbols?

[Lucy Zhang]

Hi,

I'm converting a coredump into the ELF format. At first, the outputs in GDB
came out blank, i.e.
#0 0x40091aa5 in ?? ()


But after I added some other infomation, now I get the symbols filled in.
i.e.

#0 0x40091aa5 in sigset (sig=-1073747472, disp=0x20) at
    ../sysdeps/posix/sigset.c:69

Where does GDB find the function names, the arg lists, and other such
information?

Thanks,
Lucy

Re: how does GDB find the symbols?

[Jim Blandy]

"Lucy Zhang" <lucyz@uclink4.berkeley.edu> writes:
> I'm converting a coredump into the ELF format. At first, the outputs in GDB
> came out blank, i.e.
> #0 0x40091aa5 in ?? ()
> 
> 
> But after I added some other infomation, now I get the symbols filled in.
> i.e.
> 
> #0 0x40091aa5 in sigset (sig=-1073747472, disp=0x20) at
>     ../sysdeps/posix/sigset.c:69
> 
> Where does GDB find the function names, the arg lists, and other such
> information?

From the executable file's debugging info.