From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-9359-listarch-gdb=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 5500 invoked by alias); 26 Jun 2002 19:45:55 -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 5485 invoked from network); 26 Jun 2002 19:45:53 -0000
Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35)
  by sources.redhat.com with SMTP; 26 Jun 2002 19:45:53 -0000
Received: by zwingli.cygnus.com (Postfix, from userid 442)
	id B69355EA11; Wed, 26 Jun 2002 14:45:51 -0500 (EST)
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Andrew Cagney <ac131313@cygnus.com>,
	James Cownie <jcownie@etnus.com>, gdb@sources.redhat.com
Subject: Re: GDB support for thread-local storage
References: <20020625154201.GB17370@branoic.them.org>
	<17MsdN-0Qe-00@etnus.com> <20020625155555.GA18083@branoic.them.org>
	<3D1897DA.90405@cygnus.com> <20020625170147.GB19950@branoic.them.org>
From: Jim Blandy <jimb@redhat.com>
Date: Wed, 26 Jun 2002 12:45:00 -0000
In-Reply-To: <20020625170147.GB19950@branoic.them.org>
Message-ID: <npwusl4yds.fsf@zwingli.cygnus.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-06/txt/msg00273.txt.bz2


Daniel Jacobowitz <drow@mvista.com> writes:
> On Tue, Jun 25, 2002 at 12:18:34PM -0400, Andrew Cagney wrote:
> > >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.
> > 
> > Does the current thread-db code at least sanity check version match 
> > internally?
> 
> I don't believe it has any mechanism for this, no.

Doesn't libthread_db read `struct _pthread_descr_struct' from the
linuxthreads library in the inferior, rather than knowing the layout
itself?  So it's actually the inferior's linuxthreads library that
describes its own structures' layout.

It's got *some* defense against version skew.