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

[Tye, Tony]

Another question that has been raised as part of the HSA Foundation (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.

Thanks,
Tony Tye
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160727/234afcc4/attachment.htm>