[Dwarf-Discuss] data-location containing "DW_OP_push_object_address / DW_OP_deref" if the variable could be in memory or register

[Martin]

The problem was already described here 
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2005-April/002844.html
But the replies in that thread only answered the case for DW_AT_frame_base


However, if you have a data-type like described

- At "Address of variable": e.g. pointer to 0x1234
- At 0x1234: some data, e.g. a structure or array

Note, that the address of the variable can not be 0x1234, as taking the 
address of the variable "&var" should return a pointer to the first block.

The variable can have a DW_AT_location
- that is an address in memory
- the name of a register
- a location list, that returns sometimes an address,
   sometimes a register

In order to access data at 0x1234, the data type would have an 
DW_AT_data_location like:
   DW_OP_push_object_address, DW_OP_deref, ...
(maybe followed by an adding an offset or other OPs)

But that only works for memory locations. (at least various emails on 
the list suggest this)


How can such a type be represented?

Since DW_OP_push_object_address is documented
> The DW_OP_push_object_address operation pushes the address of the object
> 3 currently being evaluated

it would be good if DW_OP_deref would always work.

DW_OP_regN
> The DW_OP_reg<n> operations encode the names of up to 32 registers,
> 8 numbered from 0 through 31, inclusive. The object addressed is in register n

The last sentence can be read that this is "the address" of that register.

If so, then maybe DW_OP_deref should be documented to fetch the value in 
the register.

The above example also illustrates why the register-content should be 
the result of the dereferencing, as it leads to the same final address 
(and that is correct if it is the same variable to start with)


And there is more:
The part of the variable data that is 0x1234 could be stored across 
several registers. Then the DW_AT_location of the variable would contain 
several DW_OP_piece.

There is an example that gives some clue what should happen, if a 
DW_AT_location returns a value like this.
Page 291 (Dwarf 5)
> DW_OP_lit1 DW_OP_stack_value DW_OP_piece 4 DW_OP_breg3 0 DW_OP_breg4 0
> 1110 DW_OP_plus DW_OP_stack_value DW_OP_piece 4
> The object value is found in an anonymous (virtual) location 

So DW_OP_piece also returns a location (albeit a virtual one). That 
could then also be dereferenced by DW_OP_deref (or maybe it already can?).

IMHO, that should be explicitly clarified. Or alternatives should be given.


** Actual real world example.

FPC (Free Pascal) has several types, that have such an hidden pointer. 
(AnsiString (array of char), dynamic array, objects)

The "pointer part" is being passed around as the variable (e.g. as a 
function parameter, or on assignment).
All variables that have the same value in the "pointer part" share the 
same data in the "pointed to part".

So the pointer-part could be ending up in a register. But the type must 
still be able to describe the data location.