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

Tony Tye
Dwarf-Discuss mailing list

Reply via email to