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: James Cownie <jcownie at etnus dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 25 Jun 2002 16:31:15 +0100
- Subject: Re: GDB support for thread-local storage
Daniel Jacobowitz wrote :-
> 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.
So, ask the thread library folks to provide a suitable versioning
symbol. As you rightly point out trying to guess the version is
unlikely to succeed !
> 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.
However, having a version on the host had already been posited by
someone else. I didn't make that part of the proposal.
I'm merely suggesting a way around the version skew which you cited as
the primary problem.
Since libthread_db is always dlopened anyway,
( http://sources.redhat.com/ml/libc-alpha/2000-06/msg00048.html )
it seems to me that you already need a good version symbol, or else
how can you handle programs which are using different versions on libc
and associated different versions of the threads library ?
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com