From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30961 invoked by alias); 21 Jun 2002 19:34:30 -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 30922 invoked from network); 21 Jun 2002 19:34:27 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 21 Jun 2002 19:34:27 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 561D35EA11; Fri, 21 Jun 2002 14:34:26 -0500 (EST) To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020619160004.38A625EA11@zwingli.cygnus.com> <3D1282DD.7000508@cygnus.com> From: Jim Blandy Date: Fri, 21 Jun 2002 12:34:00 -0000 In-Reply-To: <3D1282DD.7000508@cygnus.com> 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/msg00170.txt.bz2 Andrew Cagney writes: > > I've posted a note to the Dwarf mailing list, describing the > > DW_OP_push_tls_address approach, and saying that we'll experiment with > > this as a GNU extension to Dwarf and write back when we've actually > > got something working. > > Hmm, would you be able to post the prososal here? Sure thing. (I re-used most of the language in the Dwarf proposal in the message you replied to, so you've seen almost all of it already.) Something to make clear, though --- this isn't a "proposal" proper. The way the Dwarf committee operates (or the way I think it should operate, and thus the way I try to deal with it) is: - you float an idea by them for general approval; - then you go off and implement it as a vendor extension; - then once you've got it actually working you come back and make it a real proposal; - if it's accepted you get assigned proper numbers (not in the vendor extension range) for your attribute tags, die tags, and so on; - and finally you switch your emitter to recognize the real numbers. So this is in the "float an idea by them" stage. Very preliminary. $Id: dwarf,v 1.4 2002/06/12 21:44:14 jimb Exp $ (The function of DW_OP_push_tls_address is similar to that of the run-time function __get_tls_addr, so it was tempting to name the operation DW_OP_get_tls_addr. However, DW_OP_push_tls_address is more consistent with the names of the other operations, especially DW_OP_push_object_address.) To section 2.4.1.3, "Stack Operations", add the following paragraphs after DW_OP_push_object_address: 12. DW_OP_push_tls_address The DW_OP_push_tls_address operation pushes the base address of the current thread's thread-local storage block. If the expression occurs in the Dwarf information for a dynamically loaded library, then DW_OP_push_tls_address pushes the base address of that library's block for the current thread. If the library's storage for the current thread has not yet been allocated, a Dwarf consumer may arrange for it to be allocated now, or report an error to the user. Some implementations of C and C++ support a ``__thread'' storage class, for variables that occupy distinct memory in distinct threads. For example, the definition: __thread int foo; declares an integer variable named ``foo'' which has a separate value and address in each thread, much as a variable declared ``auto'' has a separate value and address in each invocation of the function containing its declaration. Creating a new thread creates a new instance of ``foo'', and when the thread exits, the storage for ``foo'' is freed. Typically, a program includes an ``initialization image'' --- a block of memory containing the initial values for any thread-local variables it defines. When the program creates a new thread, the run-time system allocates a fresh block of memory for those thread-local variables, and copies the initialization image into it to give the variables their initialized values. A dynamically loaded library may also define thread-local variables. Some implementations delay allocating memory for such variables until the thread actually refers to them for the first time. This avoids the overhead of allocating and initializing the library's thread-local storage for all the threads present in a program when the library is loaded, even though only a few threads might actually use the library. However, when an implementation allocates thread-local storage on demand, this makes it hard to describe the location of a thread-local variable using ordinary Dwarf expressions: referencing the storage may entail allocating memory, copying an initialization image into place, registering it with the thread, and so on. A dedicated operation like DW_OP_push_tls_address leaves this complicated task to the debugger, which is presumably already familiar with the program's ABI and thread system, and can handle the request appropriately.