[RFC PATCH] Typed DWARF stack

[Cary Coutant]

> Should DW_OP_bra be restricted to integral types?  Several other opcodes
> are restricted in this way, and it seems like an oversight to me that
> DW_OP_bra is lacking this restriction.  (I've added this restriction in
> GDB.)

Yes, that was an oversight.

> Currently, the comparison operators are all defined as performing signed
> operations.  So, what should happen in this case:
>
>   DW_OP_lit0
>   DW_OP_GNU_convert <unsigned int>
>   DW_OP_GNU_const_type <unsigned int> -1
>   DW_OP_gt
>
> That is, should this ignore the type (perhaps just using the type
> width), or is this a bug in the spec?
>
> Either answer here has problems.
>
> You can't really ignore the type, because that rules out floating point
> comparisons.  I suppose you could special-case integral types.
>
> However, since "ordinary" (that is, pre-typed-DWARF) DWARF values do not
> have a consistent type, I think answering "bug" means having a special
> case for such values -- because they are treated as unsigned in most
> places, but signed in a few, and signed/unsigned type conversion should
> presumably only be done for such "typeless" values, not all values.
>
> I think I will implement the latter ("bug") approach.

Yes, another oversight; I should have removed the sentence "The
comparisons are done as signed operations." For untyped values, it
should be reasonable to treat them as signed integers here as you
propose.

Technically, there weren't supposed to be untyped values at all in
this proposal; I should have also gone through and specified an
explicit type for each of the legacy operators that push a value onto
the stack, but signed-vs-unsigned is such a mess that I didn't bother
to go that far for a draft proposal that didn't get very far in
committee. I think a signed/unsigned cleanup in DWARF would have to go
far beyond the expression evaluation mechanism.

-cary