From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28347 invoked by alias); 19 Jun 2002 20:40:13 -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 28311 invoked from network); 19 Jun 2002 20:40:08 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 19 Jun 2002 20:40:08 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id D5F445EA11; Wed, 19 Jun 2002 15:40:06 -0500 (EST) To: Daniel Berlin Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: From: Jim Blandy Date: Wed, 19 Jun 2002 13:40:00 -0000 In-Reply-To: Message-ID: 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/msg00152.txt.bz2 Daniel Berlin writes: > > The function one may need to invoke to find thread-local storage, > > __tls_get_addr, is an actual native code function, in the dynamic > > linker. The DW_OP_call_* operations allow a Dwarf expression to call > > another Dwarf expression like a function. But you can't use the > > DW_OP_call_* operations to invoke machine-language functions in the > > inferior. > > You've assumed you need to. > If you can transform tls_get_addr into a dwarf expression, there you go. > You can deref memory, you just can't store into it. > Since the TLS address is just a location somewhere, computed without > modifying anything, one should be able to transform it pretty easily. > > Not that this is the best idea, but it's a possibility. > :) We did try to find a way to just express this as a Dwarf expression, before we resorted to a custom opcode and a libthread_db function. One objection was that this would embed knowledge about the implementation of TLS in the executable's debugging info. The way to find TLS can change depending on which dynamic linker and thread library you happen to be (dynamically) linking against. The process for finding TLS really should be tightly coupled with the actual dynamic linker and thread library in use, the way libthread_db is. One could put the right Dwarf expression in the thread library or dynamic linker's debugging info, and use DW_OP_call* to invoke it that way --- that would get the coupling right. But GDB doesn't apply dynamic relocs to its debugging info (and it's hard to see exactly how it could without a lot more help from the dynamic linker --- see Uli's TLS paper). This makes it hard to get the right operand for the DW_OP_call4/8/whathaveyou. There is also another problem I didn't mention. You need to know the module number in order to look up its TLS. The dynamic linker doesn't assign the module a number until it's loaded. But perhaps the Dwarf expression could actually get that from a GOT entry.