This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 19 Jun 2002 13:08:04 -0400 (EDT)
- Subject: Re: GDB support for thread-local storage
On Wed, 19 Jun 2002, Jim Blandy wrote:
>
> I'd like to extend GDB to support thread-local variables. Richard
> Henderson, Ulrich Drepper and I have come up with some pieces of the
> solutions; pretty much everything outside GDB has been settled, but
> I'm still trying to figure out how GDB will pull the pieces together.
>
> This post describes:
> - the feature we're trying to support,
> - the parts we've worked out so far, and
> - the parts in GDB that I'm still trying to sort out.
>
> 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.
>
> Thread-local storage requires support in the ABI, and support in the
> dynamic linker, if you want reasonable performance. There's a
> complete description of how it's done on the IA-32, IA-64, and SPARC
> at http://people.redhat.com/drepper/tls.pdf. This is based on
> specifications already written for the IA-64 and SPARC; I think the
> IA-32 implementation is Ulrich Drepper's work.
>
> For GDB, the first question is: how should the debugging information
> describe the location of a thread-local variable? We generally answer
> this sort of question by looking at how the code generated by the
> compiler finds the variable, and then emitting debugging information
> that matches that.
>
> To allow the run-time system to allocate thread-local storage on
> demand, the ABI in certain circumstances requires the compiler to emit
> a call to a function, __tls_get_addr, to find the address of a
> thread-local variable for the current thread and a particular module.
> This function looks up the address in a table, allocates and
> initializes the storage if necessary, and returns its address.
>
> Unfortunately, Dwarf 2 location expressions cannot perform function
> calls in the inferior.
Errr, buzz.
See DW_OP_call_* in dwarf3
It's not just turing complete anymore, one could probably write useful
application extensions in dwarf3.
Scary.
--Dan