On 07/19/2018 10:30 AM, Richard Biener wrote:
> On Wed, Jul 18, 2018 at 3:42 PM Tom de Vries <tdevr...@suse.de> wrote:
>>
>> On 07/06/2018 12:28 PM, Richard Biener wrote:
>>> On Thu, Jul 5, 2018 at 4:12 PM Tom de Vries <tdevr...@suse.de> wrote:
>>>>
>>>> On 07/05/2018 01:39 PM, Richard Biener wrote:
>>>>> On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries <tdevr...@suse.de> wrote:
>>>>>>
>>>>>> [ was: Re: [testsuite/guality, committed] Prevent optimization of local
>>>>>> in
>>>>>> vla-1.c ]
>>>>>>
>>>>>> On Wed, Jul 04, 2018 at 02:32:27PM +0200, Tom de Vries wrote:
>>>>>>> On 07/03/2018 11:05 AM, Tom de Vries wrote:
>>>>>>>> On 07/02/2018 10:16 AM, Jakub Jelinek wrote:
>>>>>>>>> On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
>>>>>>>>>> Given the array has size i + 1 it's upper bound should be 'i' and 'i'
>>>>>>>>>> should be available via DW_OP_[GNU_]entry_value.
>>>>>>>>>>
>>>>>>>>>> I see it is
>>>>>>>>>>
>>>>>>>>>> <175> DW_AT_upper_bound : 10 byte block: 75 1 8 20 24 8 20 26
>>>>>>>>>> 31
>>>>>>>>>> 1c (DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl;
>>>>>>>>>> DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus)
>>>>>>>>>>
>>>>>>>>>> and %rdi is 1. Not sure why gdb fails to print it's length. Yes,
>>>>>>>>>> the
>>>>>>>>>> storage itself doesn't have a location but the
>>>>>>>>>> type specifies the size.
>>>>>>>>>>
>>>>>>>>>> (gdb) ptype a
>>>>>>>>>> type = char [variable length]
>>>>>>>>>> (gdb) p sizeof(a)
>>>>>>>>>> $3 = 0
>>>>>>>>>>
>>>>>>>>>> this looks like a gdb bug to me?
>>>>>>>>>>
>>>>>>>>
>>>>>>>> With gdb patch:
>>>>>>>> ...
>>>>>>>> diff --git a/gdb/findvar.c b/gdb/findvar.c
>>>>>>>> index 8ad5e25cb2..ebaff923a1 100644
>>>>>>>> --- a/gdb/findvar.c
>>>>>>>> +++ b/gdb/findvar.c
>>>>>>>> @@ -789,6 +789,8 @@ default_read_var_value
>>>>>>>> break;
>>>>>>>>
>>>>>>>> case LOC_OPTIMIZED_OUT:
>>>>>>>> + if (is_dynamic_type (type))
>>>>>>>> + type = resolve_dynamic_type (type, NULL,
>>>>>>>> + /* Unused address. */ 0);
>>>>>>>> return allocate_optimized_out_value (type);
>>>>>>>>
>>>>>>>> default:
>>>>>>>> ...
>>>>>>>>
>>>>>>>> I get:
>>>>>>>> ...
>>>>>>>> $ ./gdb -batch -ex "b f1" -ex "r" -ex "p sizeof (a)" vla-1.exe
>>>>>>>> Breakpoint 1 at 0x4004a8: file vla-1.c, line 17.
>>>>>>>>
>>>>>>>> Breakpoint 1, f1 (i=i@entry=5) at vla-1.c:17
>>>>>>>> 17 return a[0];
>>>>>>>> $1 = 6
>>>>>>>> ...
>>>>>>>>
>>>>>>>
>>>>>>> Well, for -O1 and -O2.
>>>>>>>
>>>>>>> For O3, I get instead:
>>>>>>> ...
>>>>>>> $ ./gdb vla-1.exe -q -batch -ex "b f1" -ex "run" -ex "p sizeof (a)"
>>>>>>> Breakpoint 1 at 0x4004b0: f1. (2 locations)
>>>>>>>
>>>>>>> Breakpoint 1, f1 (i=5) at vla-1.c:17
>>>>>>> 17 return a[0];
>>>>>>> $1 = 0
>>>>>>> ...
>>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> When compiling guality/vla-1.c with -O3 -g, vla 'a[i + 1]' in f1 is
>>>>>> optimized
>>>>>> away, but f1 still contains a debug expression describing the upper
>>>>>> bound of the
>>>>>> vla (D.1914):
>>>>>> ...
>>>>>> __attribute__((noinline))
>>>>>> f1 (intD.6 iD.1900)
>>>>>> {
>>>>>> <bb 2>
>>>>>> saved_stack.1_2 = __builtin_stack_save ();
>>>>>> # DEBUG BEGIN_STMT
>>>>>> # DEBUG D#3 => i_1(D) + 1
>>>>>> # DEBUG D#2 => (long intD.8) D#3
>>>>>> # DEBUG D#1 => D#2 + -1
>>>>>> # DEBUG D.1914 => (sizetype) D#1
>>>>>> ...
>>>>>>
>>>>>> Then f1 is cloned to a version f1.constprop with no parameters,
>>>>>> eliminating
>>>>>> parameter i, and 'DEBUG D#3 => i_1(D) + 1' turns into 'D#3 => NULL'.
>>>>>> Consequently, 'print sizeof (a)' yields '0' in gdb.
>>>>>
>>>>> So does gdb correctly recognize there isn't any size available or do we
>>>>> somehow
>>>>> generate invalid debug info, not recognizing that D#3 => NULL means
>>>>> "optimized out" and thus all dependent expressions are "optimized out" as
>>>>> well?
>>>>>
>>>>> That is, shouldn't gdb do
>>>>>
>>>>> (gdb) print sizeof (a)
>>>>> <optimized out>
>>>>>
>>>>> ?
>>>>
>>>> The type for the vla gcc is emitting is an DW_TAG_array_type with
>>>> DW_TAG_subrange_type without DW_AT_upper_bound or DW_AT_count, which
>>>> makes the upper bound value 'unknown'. So I'd say the debug info is valid.
>>>
>>> OK, that sounds reasonable. I wonder if languages like Ada have a way
>>> to declare an array type with unknown upper bound but known lower bound.
>>> For
>>>
>>> typedef int arr[];
>>> arr *x;
>>>
>>> we generate just
>>>
>>> <1><2d>: Abbrev Number: 2 (DW_TAG_typedef)
>>> <2e> DW_AT_name : arr
>>> <32> DW_AT_decl_file : 1
>>> <33> DW_AT_decl_line : 1
>>> <34> DW_AT_decl_column : 13
>>> <35> DW_AT_type : <0x39>
>>> <1><39>: Abbrev Number: 3 (DW_TAG_array_type)
>>> <3a> DW_AT_type : <0x44>
>>> <3e> DW_AT_sibling : <0x44>
>>> <2><42>: Abbrev Number: 4 (DW_TAG_subrange_type)
>>> <2><43>: Abbrev Number: 0
>>>
>>> which does
>>>
>>> (gdb) ptype arr
>>> type = int []
>>> (gdb) ptype x
>>> type = int (*)[]
>>> (gdb) p sizeof (arr)
>>> $1 = 0
>>>
>>> so I wonder whether the patch makes it print <optimized out>
>>> instead? I think both 0 and <optimized out> are less than ideal
>>> and maybe <variable size> would be better. In the type case
>>> above it's certainly not "optimized out".
>>>
>>
>> I ran into trouble with the earlier posted gdb patch, in
>> gdb/testsuite/gdb.fortran/vla-sizeof.exp.
>>
>> I've submitted a second try to gdb-patches ("[PATCH][exp] Interpret size
>> of vla with unknown size as <optimized out>" at
>> https://sourceware.org/ml/gdb-patches/2018-07/msg00541.html ). It
>> handles the zero-sized array in the C example above correctly.
>
> Thanks. Without -gstrict-dwarf we can use DW_OP_GNU_variable_value
> and if that doesn't have a location it should be <optimized out>.
>
> I wonder if it makes sense to disambiguate things from the gcc side
> by generating an empty location description for known optimized out
> values (the standard seems to explicitely call that out as a way to
> say "optimized out").
Agreed, that makes sense, and thanks for pointing that out. [ Found it
at dwarf5 doc, 2.6.1.1.1 Empty Location Descriptions. ]
If I manage to find or construct a test-case where this is applicable on
trunk, I'll take a look.
Thanks,
- Tom
> Because int a[] is different from int a[x] where
> x is optimized out.
>
