Re: GDB support for thread-local storage

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jun 21, 2002 at 05:46:05PM -0400, Andrew Cagney wrote:
> >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.
> 
> Yes.
> 
> > I'd call the libthread_db
> >approach broken for this purpose (a little outside its design scope
> >perhaps).
> 
> I think it reflects limitations of the current libthread-db interface 
> rather than a broken approach.

I disagree... the concept of having a "libthread_db" with an interface
involves it being a target library, part of the system.  Unless you
change its "interface" to be a data file rather than code, it requires
access to a target in order to interpret target data.  That's my whole
objection to it.

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