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 Tue, Jun 25, 2002 at 04:31:15PM +0100, James Cownie wrote:
>
> 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 !
Anything that requires changes to the library isn't really viable; too
many libraries already exist.
> > 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 ?
We can't. It is always dlopened on the host when debugging natively
and on the target when debugging remotely, but that's it.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer