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

[Joel Brobecker <brobecker at adacore dot com>]

> But this would still require the address to be communicated to the
> property evaluation functions as the type still needs to be resolved
> using resolve_dynamic_type. Usually resolve_dynamic_type will be called
> through value_from_contents_and_address, which generates you a resolve
> type in a value object. Do you have a concrete Fortran code example,
> where you think the current implementation might go wrong?

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

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.

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.

And the concrete situation that triggered all these questions
is code in ada-lang.c. Take for instance ada_array_bound, which
takes an unresolved array as a struct value (ARR), and returns
the lower/higher bound for the nth dimension:

    ada_array_bound (struct value *arr, int n, int which)

The function essentially finds ARR's N'th index type and calls
resolve_dynamic_type on that type. If you actually look at
the code, it's slightly indirect, but it's the idea.

    ada_array_bound
      -> ada_array_bound_from_type
           -> ada_discrete_type_high_bound
                -> resolve_dynamic_type

Now, what address am I supposed to pass to resolve_dynamic_type?
The simple answer would be "the address of the array", but then,
we get back to the question I have been trying to ask: ARR may
not be an lval_memory, in which case "the address of the array"
is meaningless. And reducing a struct value back to an address
feels like information degradation. To give even more context,
I know there are bugs in GDB I can't fix until I convert it from
contents-and-address to values, except the conversion appears
hard to do on its own. So, I think it's worth pausing on this
a little, and try to think things through before we decide that,
indeed, an address is sufficient for our expected needs.

-- 
Joel