[committed] Add testcase for DW_AT_count referencing a variable

[Tom de Vries]

On 11/25/20 4:10 PM, Gary Benson wrote:
> Tom de Vries wrote:
>> On 11/16/20 6:52 PM, Gary Benson via Gdb-patches wrote:
>>> Clang describes the upper bounds of variable length arrays using
>>> a DW_AT_count attribute which references the DIE of a synthetic
>>> variable whose value is specified using a DW_AT_location.  In some
>>> cases GDB correctly handles these, but in other cases GDB adds an
>>> extra dereference causing the test to fail.  This commit adds a
>>> new test to gdb.dwarf2/count.exp with the same DWARF as that
>>> generated by Clang for gdb.base/vla-optimized-out.exp, one of the
>>> failing tests.
>>>
>>> Checked on Fedora 32 x86_64, with GCC and Clang.  Ok to commit?
>>
>> I wrote a test-case myself here (
>> https://sourceware.org/pipermail/gdb-patches/2020-November/173438.html )
>> and only after that found your patch.
> 
> I hate when that happens!
> 

Oh well.  I guess I prefer to look at it as review preparation ;)

>> I'm committing this patch (with you marked as author obviously),
>> because it's more complete, and the kfails allow us to commit it
>> before having a fix.
> 
> Cool.
> 
>> There was one problem: the DWARF expression was missing the
>> DW_OP_stack_value, I've added that.
> 
> Thanks.  FWIW I hadn't seen the "Implicit Location Descriptions" bit
> in the spec, I just constructed an expression to end with the value
> I wanted, but having read it now it seems it was a mistake that I'd
> omitted it.
> 
> Reading that bit of the spec, though, it mentions three operations
> that specify a value is an implicit location: DW_OP_stack_value,
> as you've mentioned, but also DW_OP_implicit_value and
> DW_OP_implicit_pointer.  It *doesn't* mention DW_OP_fbreg, which
> Clang uses in the DWARF it generates for gdb.base/vla-ptr.exp
> (https://sourceware.org/bugzilla/attachment.cgi?id=12970), but
> I haven't checked what's actually at that location, the count
> itself, or its address.
> 

Yes, it doesn't mention DW_OP_fbreg as implicit location, because it's a
memory location description (see 2.6.1.1.3 Implicit Location Descriptions).

Thanks,
- Tom

>> Also, I've updated the commit message to better reflect what the
>> actual problem is.
> 
> Thank you.  If you'd asked me beforehand I'd have said to put both our
> names in there, to reflect the work you've put into this.  It's too
> late to change this one now I guess, I'm more commenting in case
> something similar comes up in future.
> 
> Cheers,
> Gary
>