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 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


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