From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22371 invoked by alias); 22 Jun 2002 15:22:56 -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 22356 invoked from network); 22 Jun 2002 15:22:52 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 22 Jun 2002 15:22:52 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8222F3DD0; Sat, 22 Jun 2002 11:22:49 -0400 (EDT) Message-ID: <3D149649.8050403@cygnus.com> Date: Sat, 22 Jun 2002 08:22: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: Daniel Jacobowitz Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020621014821.GA7608@nevyn.them.org> <3D135FE5.6090605@cygnus.com> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00200.txt.bz2 > 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? > 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. Andrew