This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: debugging threaded apps. thread ID missing in corefile.
On Tue, Jun 07, 2005 at 06:46:13AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 6 Jun 2005 20:09:44 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com
> >
> > On Mon, Jun 06, 2005 at 05:33:09PM -0500, Manoj Iyer wrote:
> > >
> > > Regarding debugging threaded apps, gdb does not display the pthread id (ID
> > > returned by pthread_self() ) when reading information from a corefile.
> >
> > Yes. You can find information about this decision in the list
> > archives. We need to use libthread_db.so.1 to retrieve thread IDs, and
> > we do not have a graceful way to use it for only core dumps which
> > belong to the native system (as opposed to sysrooted or cross core
> > dumps).
>
> If this situation is not going to be changed RSN, I suggest to say
> this in the manual. Any objections?
No objection from me. I'm not planning to change it, because (a)
thread IDs are mostly cosmetic, and (b) the cross-debugging case is
more important to me than the native case.
> Btw, the node "Threads" in the manual sounds at least a little
> outdated: e.g., it only mentions Solaris and HP-UX as platforms
> capable of supporting multi-threaded debuggees. Could someone in the
> know please read that node and see if it needs to be updated in any
> significant way?
I just took a look at it; I think it's fine. It also mentions SGI and
Lynx further down; the Lynx code is I think removed now, but still
serves as a valid example here.
> > > Where as when debugging the program live it is able to display the pthread
> > > id (I dont know why the ID is a negative number, could be a bug?).
> >
> > Not really. The ID is a pointer above 0x80000000, used by the
> > implementation.
>
> Well, then perhaps we should display the thread ID in hex?
Hmm. I wouldn't object to this. The number is opaque to the user
code; for LinuxThreads it is an encoded index into an array (usually
between 0 and 64k; the first few threads are numbered around 32k and
16k). That looks plausible in hex or in decimal. For NPTL they are
pointers and would look more plausible in hex.
--
Daniel Jacobowitz
CodeSourcery, LLC