This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
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