This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]