Re: GDB support for thread-local storage

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Jun 21, 2002 at 03:08:03PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Fri, Jun 21, 2002 at 01:18:29PM -0400, Andrew Cagney wrote:
> > > >>BTW, what happens if the target doesn't have execution (i.e. a corefile).
> > > >
> > > >We fall down, just like we do debugging thread_db capable corefiles,
> > > >I'd imagine.  Thread_db does not like read-only targets very much.
> > > 
> > > GDB on a threaded GNU/Linux target, again falls down, sigh!  We can 
> > > hopefully have it working on other platforms.
> > 
> > I beg your pardon?  This is a thread_db limitation, not a GNU/Linux
> > limitation.  GNU/Linux copied the interface from Solaris and I believe
> > we use it on Solaris.  The effect there will be even more extreme than
> > on GNU/Linux.  <check> Yes, we do use it on Solaris.
> > 
> > If threaded corefiles work on Solaris I doubt it's by merit of
> > thread_db.
> 
> We can debug multi-threaded core files on Linux; see below.  I must be
> missing the point.  But this works because the core file reader
> actually goes and constructs the thread list itself.  We're not using
> thread_db to handle that.  Which is sort of a bug --- what you see
> when you run GDB on such a core file are LWP's, not threads.

Yes.  Search the archives to see the patch I committed to make this
"bug" happen instead of trying to use libthread_db; that message also
describes the problems.

And if you're feeling ambitious, search for the message which describes
why it broke libthread_db support for static executables.  I haven't
thought of a solution yet.

> Why aren't we using thread_db, though?  Why can't we run thread_db and
> simply serve its memory and register requests from the core file?  I
> don't see which part of the interface makes this impossible.  And
> we'll need to do it if Linux switches to an NxM thread model, no?

It's not interface but implementation.  There's all sorts of places
where libthread_db wants to write to the inferior.  If you fake memory
writes, it is possible that this would work; I couldn't figure out how
to do that non-intrusively.

Of much more interest to me is the fact that the LWP view of core files
can be supported cross-platform and the thread_db view of core files
can not be.  That is IMO a very substantial design flaw in
libthread_db.  Not a problem if all the world's a SPARC, but after the
effort I and others went through in order to make cross core debugging
functional I'm reluctant to use libthread_db anywhere I can avoid it.

An M:N implementation of libthread_db is even more likely to want to
write to or signal the inferior process.  I don't know if Sun's handles
this gracefully or if they grub through the corefile looking for
threads like we do.

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