On 27/10/2021 17:34, John DelSignore wrote:
One of the key concepts in the extensions, which I think addresses the
problem you described, is to make locations (memory, register,
composite, implicit, and undefined) first-class objects that can be
pushed onto the DWARF evaluation stack.
Certainly relates to the problem. I would have just called them all
"address" in different address spaces.
Register already have ordinal/numeric "addresses". They just do not
point to memory.
But yes, given its a "location expression" the word "location is better.
Dwarf5 itself introduces this (as I pointed out) in its examples
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
However, it does not allow such a location to be DW_OP_deref.
And that is the real pity. Because a member or data location, now only
works, if the new address is stored in memory.
But if a register contains a pointer, then the location of that register
can not be dereferenced to the memory location described by that pointer.
That is, to be exact: There is no single expression that can take a
memory OR register location, and deref them.
And at minute 3:02:05 they add exactly that extension:
Allow DW_OP_deref to take any location. And make the content of that
location an address pointing to memory.
making a location the /result/ of an evaluation, locations can be
pushed, popped, and operated on just like addresses and values in the
current model.
If locations can not get on the stack at all currently then what does
the following do?
- variable DW_AT_Location: DW_OP_reg1
- type DW_AT_data_location: DW_OP_push_object_address
What is now on the stack of the DW_AT_data_location?
I would have thought it is the register-location.
Meaning that the DW_AT_data_location can do no useful operation at all.
And the same applies for DW_OP_piece appearing in DW_TAG_location, which
is a virtual location and can not be processed into anything.
The problem is, that you need a different expression in
DW_AT_data_location, depending if a pointer is stored in memory or register.
Changing the DW_at_location, to return the register value, instead of
location, will not work either.
-----------------
Hoping that more debuggers adapt to the new DW_OP_deref I can use
exactly that. And it will work fine.
But then maybe it should be made part of the DWARF spec?
Personally I think DW_AT_location should always return a location.
E.g. DW_OP_stack_value should be a virtual location. (afaik that would
not even break anything)
Btw the DWARF5 says "DW_OP_stack_value operation" but contradicts this
in the examples.
If locations are used like this, then it needs to be defined which
operations can deal which with type of location.
E.g. DW_OP_deref would always take the value at the location, and treat
it as an address (memory location).
Other ops can be decided when/if needed.
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
