Re: GDB support for thread-local storage

[Jim Blandy <jimb at redhat dot com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> 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.

Great, thanks.

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

I'm not that ambitious 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.

All the calls to ps_p[td]write I see in GNU's libthread_db have to do
with the implementation of events.  Can't we just ignore those writes?
Or better yet, make gdb/thread-db.c smart enough not to set event
breakpoints in the first place when the underyling target doesn't have
execution?

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

This is the more substantial objection, it seems to me.  But simply
because libthread_db can't be used for cross-platform core files
doesn't mean we shouldn't use it in the native case --- for the same
reasons we use it on live processes.