From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15230 invoked by alias); 19 Jun 2002 20:12:23 -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 15223 invoked from network); 19 Jun 2002 20:12:22 -0000 Received: from unknown (HELO www.dberlin.org) (138.88.44.94) by sources.redhat.com with SMTP; 19 Jun 2002 20:12:22 -0000 Received: by www.dberlin.org (Postfix, from userid 503) id 39EF9182D06E; Wed, 19 Jun 2002 16:12:22 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.dberlin.org (Postfix) with ESMTP id 602EA18005D1; Wed, 19 Jun 2002 16:12:13 -0400 (EDT) Date: Wed, 19 Jun 2002 13:12:00 -0000 From: Daniel Berlin To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_MX_FOR_FROM,AWL version=2.30 X-Spam-Level: X-SW-Source: 2002-06/txt/msg00151.txt.bz2 On 19 Jun 2002, Jim Blandy wrote: > > Daniel Berlin writes: > > > Unfortunately, Dwarf 2 location expressions cannot perform function > > > calls in the inferior. > > > > Errr, buzz. > > > > See DW_OP_call_* in dwarf3 > > (As I wrote that sentence, I was wondering whether I should clarify > this point.) > > 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. :) > > > It's not just turing complete anymore, one could probably write useful > > application extensions in dwarf3. > > Scary. > > I thought so too, but then I noticed that there are no memory store > operations. You can do stuff on the stack, but you can't modify > memory, or do any I/O. Grave omissions, which should be rectified > immediately. I'm on it. It also needs a DW_OP_fix_bug >