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
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
