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