From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20645 invoked by alias); 25 Jun 2002 15:56:29 -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 20625 invoked from network); 25 Jun 2002 15:56:28 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 25 Jun 2002 15:56:28 -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 17Msg6-0001Lv-00; Tue, 25 Jun 2002 10:56:26 -0500 Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17Msfb-0004i0-00; Tue, 25 Jun 2002 11:55:55 -0400 Date: Tue, 25 Jun 2002 08:56:00 -0000 From: Daniel Jacobowitz To: James Cownie Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage Message-ID: <20020625155555.GA18083@branoic.them.org> Mail-Followup-To: James Cownie , gdb@sources.redhat.com References: <20020625154201.GB17370@branoic.them.org> <17MsdN-0Qe-00@etnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17MsdN-0Qe-00@etnus.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-06/txt/msg00250.txt.bz2 On Tue, Jun 25, 2002 at 04:53:37PM +0100, James Cownie wrote: > > > 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. > > But that seems like an argument for packing up and going for a beer > which could be applied to _any_ improvement in anything associated > with libc :-) > > The exact same argument could have been employed against introducing > libthread_db itself in the first place ! > > Surely one has to move forwards. > > Adding a suitable version symbol can only help, it can't break > anything. If it's there the debugger can use it. If not you can keep > doing what you already do, and it seems you really need it even for > the normal native cases. You'll never get them to document interface changes in pthreads' internal data structures. You're welcome to try if you like pain more than I do. The only layer the glibc folks support for accessing this data is thread_db. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer