[Dwarf-Discuss] How to represent address space information in DWARF

[Todd Allen]

On Wed, Jul 27, 2016 at 07:39:54PM -0400, Tye, Tony wrote:
>    Another question that has been raised as part of the HSA Foundation
>    ([1]http://www.hsafoundation.com/) tools working group relates to the
>    manner that address spaces should be represented in DWARF.
> 
> 
> 
>    HSA defines segments in which variables can be allocated. These are
>    basically the same as the address spaces of OpenCL. HSA defines kernels
>    that are basically the same as OpenCL kernels. A kernel is a grid launch
>    of separate threads of execution (termed work-items). These work-items are
>    grouped into work-groups. The work-items can access one of three main
>    memory segments:
> 
> 
> 
>    1. The global segment is accessible by all work-items. In hardware it is
>    typically just the global memory.
> 
>    2. The group segment (corresponding to the local address space of OpenCL)
>    is accessible only to the work-items in the same work-group. Each
>    work-group has its own copy of variables allocated in the group segment.
>    On GPU hardware this can be implemented as special hardware managed
>    scratch pad memory (not part of globally addressable memory), with special
>    hardware instructions to access it.
> 
>    3. The private segment is accessible to a single work-item. Each work-item
>    has its own copy of variables allocated in the private segment. On GPU
>    hardware this could also involve special hardware instructions.
> 
> 
> 
>    HSA also defines the concept of a flat address (similar to OpenCL generic
>    addresses). It is essentially a linearization of the addresses of the 3
>    address spaces. For example, one range of a flat address maps to the group
>    segment, another range maps to the private segment, and the rest map
>    directly to the global segment. However, it is target specific what exact
>    method is used to achieve the linearization.
> 
> 
> 
>    The following was the conclusion we reached from reading the DWARF
>    standard and looking at how gdb and lldb would use the information. We are
>    currently working on creating a patch for LLVM to support address spaces
>    and would appreciate any feedback on if this matches the intended usage of
>    DWARF features to support this style of address space.
> 
> 
> 
>    1. Use the DW_AT_address_class to specify that the value of a pointer-like
>    value is the address within a specific address space. Pointer-like values
>    include pointers, references, functions and function types. For HSA we are
>    really only concerned with pointer/reference values currently. It would
>    apply to a pointer-like type DIE, or a variable with a pointer-like type.
>    In the case of a variable it does not specify the address space of the
>    variable's location, but specifies how to treat the address value stored
>    in the variable.
> 
> 
> 
>    2. Use DW_OP_xderef in the location expression of a variable to specify
>    the address space in which the variable is located. Since location
>    expressions can specify different locations depending on the PC, this
>    allows the variable to be optimized to have multiple locations. For
>    example, sometimes in a memory location in the group address space,
>    sometimes in a register, sometimes in a memory location in the private
>    address space (maybe due to spilling of the register), etc.
> 
> 
> 
>    Attempting to use DW_AT_address_class on variables to specify their
>    address space location conflicts with DWARF stating that it applies to the
>    pointee as described in #1. It also breaks the flexibility of location
>    expressions allowing the location to change according to PC.
> 
> 
> 
>    When a debugger evaluates a DWARF location expression it can generate a
>    flat address to encode the address space. It can do this by implementing
>    the XDEREF as a target specific conversion from a segment address into a
>    flat address. Similarly when using a value as an address that has a
>    pointer-like type with an address class, the value can be converted to a
>    flat address. When accessing addresses the debugger would have to provide
>    the "current thread" so that the correct group/private address space
>    instance can be accessed when given a flat address that maps to the group
>    or private segments. It appears both gdb and lldb provide this.
> 

FWIW, the use of DW_AT_address_class on pointer & reference times also is how
Nvidia's CUDA compiler describes its various segments.  I haven't encountered
any uses of DW_OP_xderef* operators, but it probably is just because it hasn't
been necessary.

-- 
Todd Allen
Concurrent Computer Corporation