From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10384 invoked by alias); 25 Jun 2002 15:42:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10377 invoked from network); 25 Jun 2002 15:42:34 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 25 Jun 2002 15:42:34 -0000 Received: from cs2876-108.austin.rr.com ([24.28.76.108] helo=branoic) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17MsSe-0001Kv-00; Tue, 25 Jun 2002 10:42:32 -0500 Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17MsSA-0004Zl-00; Tue, 25 Jun 2002 11:42:02 -0400 Date: Tue, 25 Jun 2002 08:42:00 -0000 From: Daniel Jacobowitz To: James Cownie Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage Message-ID: <20020625154201.GB17370@branoic.them.org> Mail-Followup-To: James Cownie , gdb@sources.redhat.com References: <20020625150435.GB16178@branoic.them.org> <17MsHj-0Q3-00@etnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17MsHj-0Q3-00@etnus.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-06/txt/msg00248.txt.bz2 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