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