[Dwarf-Discuss] question on address spaces

Ashutosh Pal Ashutosh.Pal at synopsys.com
Mon Oct 5 23:53:10 PDT 2015

Hi Dwarf Experts,

We have processor architectures that have multiple overlapping address spaces. Our compiler tool-chain can map data variables (locals and globals) to these address spaces. For example:

int GMEMX array1[100];  // allocates to GMEMX
int GMEMY array2[100];  // allocates to GMEMY

void foo() {
  vint8 vec1 = init_vec();  // allocates to stack on VMEM
  int a = get_element(vec1, 1);   // allocates to stack on SMEM


In the above example, there are 4 overlapping address-spaces (GMEMX, GMEMY, VMEM and SMEM) each has one variable mapped to it respectively. To uniquely identify the variable inside debugging information, we would like to express the location of variables using a tuple <address-space-id, local-address> where the 'address-space-id' is an integer uniquely identifying the address-space, while 'local-address' is an expression that evaluates to an address with-in the corresponding address space.

So, we are looking for ways using which the locations of these variables can be expressed in the dwarf information. We found two features in the dwarf4 specification, but with both we see drawbacks:

1.       DW_AT_segment: This is an attribute that can be specified on top of variable dies. We can use this attribute to encode our 'address-space-id' and use it in tandem with DW_AT_location to describe the required tuple. But, with this we cannot cover those cases where a variable can reside in 2 address-spaces in its whole life time; for this, we would need an operator describing the address-space-id in the location description itself.

2.       DW_OP_xderef: The is the only operator that allows encoding an address-space-id along with an address. But we see 2 problems in expressing the location of say a local variable residing on stack at offset 20 on address-space-id 4:

a.        {DW_OP_bregx SP 20} {4} DW_OP_xderef: Evaluating this expression returns the value of the local variable and NOT its location.

b.      The specification also says that the size of the dereferenced value returned by DW_OP_xderef should be less than or equal to the size of the address on the target. While in our case the dereferenced values could bigger than the address. This further prohibits us in applying DW_OP_stack_value operator on the above expression

Are there other possibilities in the dwarf4 standard that we overlooked for the above scenarios? Also, any pointers to where people might have already solved such issues earlier, would be useful to have.

Thanks and Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20151006/6b65052a/attachment.htm>

More information about the Dwarf-Discuss mailing list