Issue 110803.1: DW_OP_form_tls_address semantics
Section 2.5.1.3, pg 20
DWARF4 documents DW_OP_form_tls_address as follows:
The DW_OP_form_tls_address operation pops a value from the stack,
translates it into an address in the current thread's thread-local
storage block, and pushes the address. If the DWARF expression
containing the DW_OP_form_tls_address operation belongs to the
main executable's DWARF info, the operation uses the main
executable's thread-local storage block; if the expression belongs
to a shared library's DWARF info, then it uses that shared
library's thread-local storage block.
What, exactly, is the value on the stack? Or is this determined by an
unspecified producer / consumer agreement? If the latter, then this fact
should be made explicit in the standard.
Proposal:
Revised text:
The DW_OP_form_tls_address operation pops a value from the stack,
translates this value into an address in the thread-local
storage block for a thread, and pushes the resulting address onto the
stack. The meaning of the value on the top of the stack prior to this
operation is defined by the run-time environment. If the run-time
environment supports multiple thread-local storage blocks for a single
thread, then the block corresponding to the executable or shared
library containing this DWARF expression is used.
*Some implementations of C and C++ support a __thread storage class.
Variables with this storage class have distinct values and addresses in
distinct threads, much as automatic variables have distinct values and
addresses in each function invocation. Typically, there is a single block
of storage containing all __thread variables declared in the main
executable, and a separate block for the variables declared in each shared
library. Each __thread variable can then be accessed in its block using an
identifier. This identifier is typically an offset into the block and pushed
onto the DWARF stack by one of the DW_OP_const operations prior to the
DW_OP_form_tls_address. Computing the address of the appropriate block can
be complex (in some cases, the compiler emits a function call to do it), and
difficult to describe using ordinary DWARF location descriptions. Instead of
forcing complex thread-local storage calculations into the DWARF expressions,
the DW_OP_form_tls_address allows the consumer to perform the computation
based on the run-time environment.*
----
Updated with proposal (8/14/2012).
Accepted with modification -- Sept. 18, 2012
Change "__thread storage class" to "thread local storage class" and
"__thread variables" to "thread local variables" in non-normative text.