Re: GDB support for thread-local storage

[James Cownie <jcownie at etnus dot com>]

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