Re: GDB support for thread-local storage

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Jun 21, 2002 at 03:54:12PM -0500, Jim Blandy wrote:
> 
> 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?

I tried that; there was some other problem.  It might have been in my
implementation.  Indeed upon looking back at it I see that you are
correct.  Maybe it would work.

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

Maybe.... I don't think the analogy holds.  When we use it on live
processes there is always a system (somewhere) on which thread_db could
be running.  That's why I was willing to use it in gdbserver.  Of
course, it's ONE MORE library that needs to be on all my targets now,
which I'm not in love with.

Debugging a core dump can't validly require access to a target.  So
making "native debug of a core dump" different from the hopeful "cross
debug of a core dump" seems a bit dodgy.  I'd call the libthread_db
approach broken for this purpose (a little outside its design scope
perhaps).

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