This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]