Issue 110803.1: DW_OP_form_tls_address semantics

Author: David Gross
Champion: Brock Wyma
Date submitted: 2011-08-03
Date revised:
Date closed:
Type: Clarification
Status: Accepted with modification
DWARF Version: 5
Section, 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.


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.