From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30980 invoked by alias); 24 Jun 2002 14:53:49 -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 30934 invoked from network); 24 Jun 2002 14:53:47 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 24 Jun 2002 14:53:47 -0000 Received: from cs2876-108.austin.rr.com ([24.28.76.108] helo=branoic) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17MVDq-0007rg-00; Mon, 24 Jun 2002 09:53:42 -0500 Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17MVDL-00014p-00; Mon, 24 Jun 2002 10:53:11 -0400 Date: Mon, 24 Jun 2002 07:53:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage Message-ID: <20020624145311.GA3804@branoic.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , gdb@sources.redhat.com References: <20020621173249.GA11443@nevyn.them.org> <20020621201716.GA23307@nevyn.them.org> <20020621210302.GA25010@nevyn.them.org> <3D139E9D.70401@cygnus.com> <20020621215532.GA27228@nevyn.them.org> <3D13A93D.50409@cygnus.com> <20020622055926.GB7243@nevyn.them.org> <3D149649.8050403@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D149649.8050403@cygnus.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-06/txt/msg00215.txt.bz2 On Sat, Jun 22, 2002 at 11:22:49AM -0400, Andrew Cagney wrote: > >Sorry, I'm lost here. > >> > >>Say, instead of a libthread_db, we had gdb/libthread-db.c which could be > >>compiled on all systems. It would have some sort of procedural > >>interface, and would grub around in target data to find thread X lwp > >>maps. However, it could be written in a way that was host architecture > >>netural. > > > > > >Sure. But the design of libthread_db says, "I am 100% coupled to the > >private structure of this thread implementation. I must match its > >version exactly if you want predictable results. My details can change > >in minor revisions or even more frequently." That's not part of the > >implementation; it's more like the purpose of the design. It is a > >layer between implementation-specific details with no guaranteed > >structure and a structured client interface. > > Right. > > But what is stopping us picking up that code, compiling it on the host > (not target), and then using it in GDB? Version skew primarily. If you examine the way that libthread_db works in GNU libc, you'll see that it knows the offset to various private data structures by including the internal linuxthreads implementation header. These can change between minor point-releases of glibc. We could detect the version string and have lists of offsets that way but it would mean updating GDB for every new version of glibc. This is probably feasible but mitigates the value of thread_db greatly; the principal advantage was separating the debugger from knowledge of the threads implementation. We'd have to build target data structures (the way that C++ ABI support does) and their types can vary greatly architecture to architecture. If we require libpthread.so to contain debugging information it would be a little more practical, maybe... On Solaris this isn't even an option of course. If we don't use the system libthread_db we have no way to duplicate its functionality. > >Without imposing structure on that data, I don't think it'll ever be > >possible to have a gdb/libthread-db.c. > > We'll never be able to have a single libthread-db.c file but we should > at least be able to get the interface defined, and the code implemented, > in a way that makes it possible for it to be used on the host. Perhaps for a limited set of (target arch, target lib version) pairs. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer