This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: James Cownie <jcownie at etnus dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 25 Jun 2002 11:04:35 -0400
- Subject: Re: GDB support for thread-local storage
- References: <1024952640.13693.ezmlm@sources.redhat.com> <17Mlzg-0If-00@etnus.com>
On Tue, Jun 25, 2002 at 09:48:12AM +0100, James Cownie wrote:
> > > But what is stopping us picking up that code, compiling it on the host
> > > (not target), and then using it in GDB?
> >
> > Version skew primarily.
>
> Can you not choose the right version of libthread_db at runtime based
> on the version of linuxthreads and dlopen it in gdb ?
>
> Ideally there'd be some version information in the thread library code
> which gdb could extract in a specified manner, and then a convention
> about how that maps to a the name of a suitable .so version of
> libthread_db.
But there isn't this version information. We could probably detect the
glibc version number, but these are internal structures, not
interfaces; detecting when they have changed is quite hard.
> This lets you
>
> 1) use libthread_db inside gdb on the host machine
> 2) keep gdb insulated from the version dependency on the thread
> library.
Nope. We'd have to be the ones writing such a thread_db; there is no
version that can run on the host machine at present.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer