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 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".

> Using this gdb patch:
> ...
> diff --git a/gdb/eval.c b/gdb/eval.c
> index 9db6e7c69d..ea6f782c5b 100644
> --- a/gdb/eval.c
> +++ b/gdb/eval.c
> @@ -3145,6 +3145,8 @@ evaluate_subexp_for_sizeof (...)
>         {
>           val = evaluate_subexp (NULL_TYPE, exp, pos, EVAL_NORMAL);
>           type = value_type (val);
> +         if (TYPE_LENGTH (type) == 0)
> +           return allocate_optimized_out_value (size_type);
>         }
>        else
>         (*pos) += 4;
> ...
>
> I get:
> ...
> $ ./gdb vla-1.exe -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 = <optimized out>
> ...
>
> Thanks,
> - Tom


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