From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5459 invoked by alias); 25 Jun 2002 15:31:19 -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 5391 invoked from network); 25 Jun 2002 15:31:17 -0000 Received: from unknown (HELO pc4) (80.192.14.187) by sources.redhat.com with SMTP; 25 Jun 2002 15:31:17 -0000 Received: from jcownie by etnus.com with esmtp (MasqMail 0.1.16) id 17MsHj-0Q3-00 for gdb@sources.redhat.com; Tue, 25 Jun 2002 16:31:15 +0100 To: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage In-Reply-To: Message from Daniel Jacobowitz of "Tue, 25 Jun 2002 11:04:35 EDT." <20020625150435.GB16178@branoic.them.org> Date: Tue, 25 Jun 2002 08:31:00 -0000 From: James Cownie Message-ID: <17MsHj-0Q3-00@etnus.com> X-SW-Source: 2002-06/txt/msg00245.txt.bz2 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 ! > 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 ? -- Jim James Cownie Etnus, LLC. +44 117 9071438 http://www.etnus.com