[PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Berlin]

On 28 Mar 2002, Jim Blandy wrote:

> 
> Daniel Berlin <dan@dberlin.org> writes:
> > I didn't want to deal with the issue of whether we want to return a struct 
> > value, and the issue of how best to keep track of whether it's in memory 
> > or a register, without getting an opinion first.
> 
> I spoke with Andrew on the phone yesterday, and he and I have
> different ideas about how things should go.  I don't think I
> understood the path of changes he wanted to see.
> 
> My personal inclination is to make the Dwarf 2 location expression
> interpreter as independent from GDB as possible.  It can use the
> CORE_ADDR type for stack elements, but it should take arguments
> specifying:
> - the expression as a simple char * pointer and length,
Done

> - the architecture's address size,

This is already available as a global, no?
> - function pointers for reading memory and registers that simply hand
>   back a CORE_ADDR value (thus keeping the interpreter innocent of
>   endianness issues), and

It uses functions that deal with the endianness issues for us, and are 
used elsewhere in GDB.

Remember, I test on both x86, and powerpc.
:)

> - the frame base address (for DW_OP_fbreg)

Not possible.
the frame base can be a location list.
That's why it pulls it out of the frame function on the fly. 

> 
> It should return a structure that says whether the location expression
> specified a particular register (i.e., DW_OP_reg0 and friends) or an
> address. 

This is a struct value *, in effect, which is what i'm using.

> Actually, the return value should be a list of pieces, each
> of which gives a byte length and then a register or address.

struct value needs to be modified to allow pieces anyway, so i was going 
to add the "list of pieces there", and just set the right flags.

> 
> But I tend to think it shouldn't take a struct frame_info or struct
> context, and it shouldn't return a struct value. 

It needs the context. In the case of unwinding, we need the unwinding 
context.

In order to recursively evaluate things like the fbreg, we also need the 
frame we are currently evaluating in anyway.

Lastly, as the dwarf3 doc says, "In the case of locations used for 
structure members, the computation implicitly pushes the base 
address of the immediately containing structure on the stack before 
evaluation of the addressing operation".
So we need an initial value parameter.

For pointer to members, the docs says
"

For an expression such as
object.*mbr_ptr
where mbr_ptr has some pointer to member type, a debugger should:
1. Push the value of mbr_ptr onto the location expression stack.
2. Push the base address of object onto the location expression stack.
3. Evaluate the DW_AT_use_location expression given in the type of 
mbr_ptr.
"

struct value is exact the 
abstraction you mention above, that specifies where something is.

>  Sure, you'll need
> more glue code than you would if it took just the right arguments for
> the use we have in mind, but keeping it as innocent of GDB as possible
> makes the interface easier to understand: you don't need to wonder how
> it interacts with a frame's saved registers, how it finds the frame
> base, and so on.  You can look at the code and say, "Ah, this doesn't
> worry about any of that."
The problem is it needs to.
>   There's a simple test for the module
> boundaries: if a behavior is described in the Dwarf spec chapter on
> location expressions, it should be inside; otherwise, it should be
> outside.  And once you've written frame/struct value glue code,
> everyone can use that and nobody minds.

I think you need to look a bit closer at that document.
:)
They changed location expressions to be a special case of "dwarf 
expressions".
Implicit in the definition of location expression is now that it has some 
context. In fact, the stack machine assumes such a context.

Nowhere does it actually mention how to evaluate the operations, just what 
they do.
It just assumes you can magically get and evaluate things.

> 
> What a lot of hand-waving.  Sorry.  Hopefully you'll see what I'm
> getting at.
> 
Sure, i'm just not sure it's possible.