Re: dwarf3 and location expressions et. al

[Daniel Berlin <dan at dberlin dot org>]

> I'm wondering if the thing to do is to map (baton, frame) onto a
> ``struct expression'' rather than directly onto a ``struct value''.  I'm
> wondering of the CFI stuff should also do this.

CFI definitely can't be supported with the current expression ops.

> Once you have an expression for a variable, it should be possible to use
> existing infrastructure to evaluate or encode it.
Not without adding a few opcodes, and trying to figure out a nice mapping.
I tried this once, and it didn't work out so well.
It also adds another layer.
Since the expressions are built on the fly, we'll end up reading a location expression , 
then converting it, then evaluating it.
Rather than just reading it and evaluating it.


In addition, expression evaluation is language specific.
DWARF2 locations are not.

> This also has the advantage of keeping expresion evaluation in one place
> - if the expression evaluation is ever made asynchronous then there is
> only one evaluator to fix for instance.
You've looked at this from the wrong level.

Expressions in GDB are analogous to language-dependent trees in gcc.
DWARF2 locations are analagous to a mid-level RTL (IE pretend GCC's 
RTL was language and machine independent. We'll have a mid-level RTL soon).

The language-dependent trees have type information, and all kinds of language
specific semantics.
mid-RTL has no types, and can be evaluated without any regard to the language
involved.

Same with gdb expressions (language dependent semantics, language specific ops,
type information) vs dwarf2 locations (language independent, no type info).
You don't want to mix layers like you are suggesting.
It leads to evil.

In effect, converting dwarf2 locations to struct expression's and evaluating
 would be like converting RTL back to C and compiling it.