From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12024 invoked by alias); 19 Jun 2002 19:20:47 -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 11960 invoked from network); 19 Jun 2002 19:20:46 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 19 Jun 2002 19:20:46 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 769A45EA11; Wed, 19 Jun 2002 14:20:44 -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 12:20: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/msg00150.txt.bz2 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. > 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.