Re: [PATCH 01/23] dwarf: add dwarf3 DW_OP_push_object_address opcode

[Keven Boell <keven.boell@linux.intel.com>]

> I think we're talking past each other :-(, so I'll try to explain
> in more details what I have in mind.

Yes, I think so, sorry for that :(

> 
> I do not have any concrete Fortran example for you, and I am not
> saying that the implementation is wrong. I am asking a question
> of how things should work if the object you are trying to evaluate
> and resolve actually does not live in memory. If the object does
> not live in memory (eg: lives in register), are we stuck? The answer
> might be yes, or maybe that's something that can't happen, but I would
> like to explore that question to have a better understanding of what
> we can expect to achieve.

We tried to follow the DWARF standard to get this implemented. The DWARF
standard says that this scenario cannot happen in combination with the
DW_OP_push_object_address operation:

"The DW_OP_push_object_address operation pushes the _address_ of the 
object currently being evaluated as part of evaluation of a user presented
expression [...] This operator provides explicit functionality (especially 
for arrays involving descriptors) that is analogous to the implicit push 
of the base address of a structure prior to evaluation of a 
DW_AT_data_member_location to access a data member of a structure."
DWARF Debugging Information Format, Version 4.

So I think having only the address here seems to be ok.

> 
> Ideally, I have a feeling that what we should be taking isn't
> an address, but a struct value.  The struct value object carries
> much more information, and might allow us to deal with the case
> above. Another interesting, and perhaps more likely scenario, is
> the case where part of the object is optimized out. You can't
> expect a "contents and address" to represent accurately your object,
> so chances are GDB would get it wrong.

I agree with you that having a struct value instead of an address gives 
more flexibility, but for now I think this is not required according to 
the DWARF standard. If there is a real-world use-case where a full struct 
value object is required instead of having only the address, then this
functionality can be added after this patch series.

The patch series has been outdated, due to the introduction of two 
new functions by Tom (resolve_dynamic_struct and resolve_dynamic_union). 
Shall I therefore submit version 2?

Keven