Re: GDB support for thread-local storage

Daniel Jacobowitz
2002-06-21T21:03:15Z

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