From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-9337-listarch-gdb=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 25820 invoked by alias); 25 Jun 2002 16:11:41 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 25812 invoked from network); 25 Jun 2002 16:11:39 -0000
Received: from unknown (HELO pc4) (80.192.14.187)
  by sources.redhat.com with SMTP; 25 Jun 2002 16:11:39 -0000
Received: from jcownie by etnus.com with esmtp (MasqMail 0.1.16) id
 17Msup-0Qw-00 for gdb@sources.redhat.com; Tue, 25 Jun 2002 17:11:39
 +0100
To: gdb@sources.redhat.com
Subject: Re: GDB support for thread-local storage 
In-Reply-To: Message from Daniel Jacobowitz <drow@mvista.com> 
   of "Tue, 25 Jun 2002 11:55:55 EDT." <20020625155555.GA18083@branoic.them.org> 
Date: Tue, 25 Jun 2002 09:11:00 -0000
From: James Cownie <jcownie@etnus.com>
Message-ID: <17Msup-0Qw-00@etnus.com>
X-SW-Source: 2002-06/txt/msg00251.txt.bz2


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

I'm not sugggesting that they document it, rather that they provide a
version symbol which tells you which version of the pthreads code you
have, and then name libthread_db with a name which includes the
version number.

All I'm after is that one can tell from a debugger which version of
the pthread library one is looking at and then deduce which
libthread_db.so to dlopen.

Something as trivial as

static volatile int __pthread_version_number = 123;

somwehere would probably do. 

The documentation requirement would be

  The static symbol __pthread_version_number gives the version number
 of the pthread library to allow a debugger to locate the appropriate
 version of libthread_db.

and that's it. It doesn't change...

Thought they need to remember to change the version number when they
make changes which affect libthread_db.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com