Re: [testsuite/guality, committed] Prevent optimization of local in vla-1.c

[Tom de Vries <tdevries at suse dot de>]

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

At O3, f1 is cloned to a version f1.constprop with no parameters,
eliminating parameter i, but i is still accessible via
DW_OP_GNU_parameter_ref:
...
$ ./gdb vla-1.exe -q -batch -ex "b f1" -ex "run" -ex "p i" -ex "info addr i"
Breakpoint 1 at 0x4004b0: f1. (2 locations)

Breakpoint 1, f1 (i=5) at vla-1.c:17
17        return a[0];
$1 = 5
Symbol "i" is a complex DWARF expression:
     0: DW_OP_GNU_parameter_ref offset 125
     5: DW_OP_stack_value
.
...

Variable a in f1 has full info available:
...
 <2><1f6>: Abbrev Number: 20 (DW_TAG_variable)
    <1f7>   DW_AT_name        : a
    <1f9>   DW_AT_decl_file   : 1
    <1fa>   DW_AT_decl_line   : 15
    <1fb>   DW_AT_decl_column : 8
    <1fc>   DW_AT_type        : <0x201>
 <2><200>: Abbrev Number: 0
 <1><201>: Abbrev Number: 15 (DW_TAG_array_type)
    <202>   DW_AT_type        : <0x21b>
    <206>   DW_AT_sibling     : <0x21b>
 <2><20a>: Abbrev Number: 21 (DW_TAG_subrange_type)
    <20b>   DW_AT_type        : <0x1ce>
    <20f>   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)
 <2><21a>: Abbrev Number: 0
...

but a in f1.constprop has no DW_AT_upper_bound:
...
 <2><26e>: Abbrev Number: 26 (DW_TAG_variable)
    <26f>   DW_AT_abstract_origin: <0x1f6>
    <273>   DW_AT_type        : <0x284>
 <2><283>: Abbrev Number: 0
 <1><284>: Abbrev Number: 15 (DW_TAG_array_type)
    <285>   DW_AT_type        : <0x21b>
    <289>   DW_AT_sibling     : <0x293>
 <2><28d>: Abbrev Number: 28 (DW_TAG_subrange_type)
    <28e>   DW_AT_type        : <0x1ce>
 <2><292>: Abbrev Number: 0
...

AFAIU, we could emit a DW_AT_upper_bound here as well, using
DW_OP_GNU_parameter_ref as we do for i.

Thanks,
- Tom