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

[Gary Benson via Gdb-patches <gdb-patches@sourceware.org>]

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