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