This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][debug] Handle references to skipped params in remap_ssa_name


On 07/19/2018 10:30 AM, Richard Biener wrote:
> On Wed, Jul 18, 2018 at 3:42 PM Tom de Vries <tdevries@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 <tdevries@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 <tdevries@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.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]