Re: GDB support for thread-local storage

Daniel Jacobowitz
2002-06-21T20:18:43Z

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