Re: FYI: fix big-endian bug with DWARF_VALUE_STACK

["Ulrich Weigand" <uweigand@de.ibm.com>]

Tom Tromey wrote:

> >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
> Ulrich> The original code looks broken to me too.  But even the new code
> Ulrich> doesn't seem quite right: if the requested piece size p->size
> Ulrich> is larger than addr_size, the remaining bytes of the output value
> Ulrich> are left undefined (well, probably zeroed -- but that still doesn't
> Ulrich> look correct on a big-endian machine ...).
> 
> I asked about a similar case on dwarf-discuss, namely what if you have:
> 
>   DW_OP_implicit_value[len=5] DW_OP_piece[len=10]
> 
> The answer I got was something along the lines of "that is undefined,
> don't do that".

This seems somewhat different in that the DW_OP_implicit_value explicitly
provides data of a certain length.  On the other hand, DW_OP_stack_value
refers to the value on top of the stack, which -as I understand it- is a
numerical value, not a sequence of bytes of defined length.

So it would seem to me that you should be able to request that this value
be represented in any arbitrary length ...

However, maybe I'm missing something here, in particular as I haven't been
able to find a formal specification of DW_OP_stack_value -- I assume this
is in the current DWARF4 draft?  Is this available somewhere?

> Tom> @@ -476,19 +474,17 @@ dwarf2_evaluate_loc_desc (struct symbol *var, struct frame_info *frame,
> 
> Ulrich> Similiary here; why does this not simply use value_from_longest?
> 
> It didn't occur to me; but AFAIK, nothing prohibits a DWARF expression
> from using DW_OP_stack_value to fill in a structure or union, and
> value_from_longest won't work in that case.

OK, good point, so you'd have to use store_unsigned_integer directly.
Still, the reference to ctx->addr_size seems odd to me ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com