From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4632 invoked by alias); 27 Jun 2002 02:31: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 4559 invoked from network); 27 Jun 2002 02:31:15 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 27 Jun 2002 02:31:15 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 261A23E4B; Wed, 26 Jun 2002 22:31:00 -0400 (EDT) Message-ID: <3D1A78E4.5060904@ges.redhat.com> Date: Wed, 26 Jun 2002 19:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: Daniel Jacobowitz , Andrew Cagney , James Cownie , 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00279.txt.bz2 > Daniel Jacobowitz 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. The structure layout will have been compiled into libthread-db.a. It implicitly knows the layout itself. > It's got *some* defense against version skew. To defend against version skew, libthread-db needs to check that its internals are consistent with the target. A simple variable value check was mentioned. Andrew