[committed][PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang
Tom de Vries
tdevries@suse.de
Mon Nov 30 12:51:15 GMT 2020
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
More information about the Gdb-patches
mailing list