Re: RFC: implement typed DWARF stack

[Tom Tromey <tromey@redhat.com>]

>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:

Ulrich> However, you don't really need to look specifically into Cell tests;
Ulrich> with your patch applied, I'm seeing a whole bunch of test suite
Ulrich> regressions in an -m32 test on ppc64.

Thanks, I will look into this.

Ulrich> I see.  However, the code as implemented casts *all* signed values to
Ulrich> unsigned for DW_OP_shr, not just old-style values.  That's what got
Ulrich> me confused ...

Oops, thanks for noticing that.  I fixed it locally.

Tom> What if we add a cast to dwarf_expr_fetch_address, like the appended?
Tom> I am not really sure whether this is ok.

Ulrich> Huh, interesting approach.  In a sense, that might be OK, since
Ulrich> it mirrors what we're doing in dwarf_expr_read_reg by calling
Ulrich> address_from_register.  On the other hand, I'm not sure
Ulrich> value_cast always does the right thing if the size of a pointer
Ulrich> type differs from the size of the DWARF address type ...

I had not considered that as a possibility.  I think the most obviously
safe thing to do is just revert dwarf_expr_fetch_address to (mostly)
resemble its pre-patch state.  I will do that and test it.

Ulrich> Another issue that just occurred to me: your patch creates
Ulrich> possibly many temporary struct value objects.  I'm wondering
Ulrich> whether those ought to be released from the value chain at some
Ulrich> point ...

I considered this but talked myself out of it using the following
reasoning:

1. Most DWARF expressions are simple, so in practice not many values
   will be released;
2. The unwinder code is value based but does not seem to call
   value_free_to_mark, so it must not be significant there;
3. In other (expression-evaluation) contexts, some caller is going to
   free the values anyway;
4. The watchpoint code looks at the value stack to determine what
   intermediate values to watch, and perhaps the values from the DWARF
   expression are relevant (though ... it occurs to me just now that
   this approach must be pretty broken in the presence of location
   lists).

I am actually not sure if #4 is an argument for or against.  Maybe those
intermediate values confuse things; there is a comment in
value_fetch_lazy indicating that this may be the case.

Tom