From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14562 invoked by alias); 25 Jun 2002 15:53:39 -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 14495 invoked from network); 25 Jun 2002 15:53:38 -0000 Received: from unknown (HELO pc4) (80.192.14.187) by sources.redhat.com with SMTP; 25 Jun 2002 15:53:38 -0000 Received: from jcownie by etnus.com with esmtp (MasqMail 0.1.16) id 17MsdN-0Qe-00 for gdb@sources.redhat.com; Tue, 25 Jun 2002 16:53:37 +0100 To: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage In-reply-to: Your message of "Tue, 25 Jun 2002 11:42:02 EDT." <20020625154201.GB17370@branoic.them.org> Date: Tue, 25 Jun 2002 08:53:00 -0000 From: James Cownie Message-ID: <17MsdN-0Qe-00@etnus.com> X-SW-Source: 2002-06/txt/msg00249.txt.bz2 > > 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. -- Jim James Cownie Etnus, LLC. +44 117 9071438 http://www.etnus.com