[committed][PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang

[Tom de Vries <tdevries@suse.de>]

On 11/23/20 11:34 AM, Tom de Vries wrote:
> [ 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?
> 

Committed.

Thanks,
- Tom