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

Gary Benson via Gdb-patches
2020-11-25T14:50:24Z

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?

Thank you for picking this up Tom (de Vries). Your patch looks good,
however I wanted to point out that the location expressions Clang
generates for gdb.base/vla-ptr.exp don't end with DW_OP_stack_value:

< 2><0x000000a3> DW_TAG_variable
DW_AT_location len 0x0002: 9168: DW_OP_fbreg -24
DW_AT_name __vla_expr0
DW_AT_type <0x00000118>
DW_AT_artificial yes(1)
< 2><0x000000af> DW_TAG_variable
DW_AT_location len 0x0002: 9160: DW_OP_fbreg -32
DW_AT_name __vla_expr1
DW_AT_type <0x00000118>
DW_AT_artificial yes(1)

It wasn't obvious to me how GDB with your patch would handle these.
Did you check your patch using that test?

Thanks,
Gary

--
Gary Benson - he / him / his
Principal Software Engineer, Red Hat