[ was: Re: [PATCH] KFAIL variable-length array tests which fail with Clang ]

On 11/20/20 5:51 PM, Tom Tromey wrote:
>>> I don't really understand the is_reference stuff
> 
> Tom> In case a dwarf expression is used for an DW_AT_location attribute, by
> Tom> default it represents an address, and needs to be dereferenced to get
> Tom> the value.
> 
> Yeah, I guess I'd need to see some examples to understand why this
> decision is made here and not at the point of use.
> 
>>> Anyway, gdb can't do this sort of check.  It will fail if the expression
>>> has a different shape, which is completely allowed by the spec.
> 
> Tom> AFAIU, the spec specifically says how to interpret a DW_OP_stack_value
> Tom> at the end of the dwarf expression which is used a location description,
> Tom> and the code in the patch follows that reasoning.
> ...
> Tom> So, for my understanding, can you give an example of the problem you're
> Tom> envisioning?
> 
> Nothing prevents an expression from ending with some other DW_OP_* with
> 0x9f as an operand to the opcode.  This would confuse this simple
> checker.  Or to put it another way, nothing guarantees that the last
> byte of an expression is an opcode.  I think it could even be both,
> depending on a runtime condition, because AFAIK nothing prevents a DWARF
> expression from branching to the middle of some other operation.

Hmm, indeed, thanks for pointing this out.  That means that this needs
to be dealt with in the evaluator.  AFAICT, DWARF_VALUE_STACK is used
already to represent the DW_OP_stack_value op in the evaluator, it's
just not used for this scenario.

Another try below.  Any more comments?

Thanks,
- Tom