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
...
So I'd say it's a gdb bug indeed.
Thanks,
- Tom
>> Btw, the location expression looks odd, if I deciper it correctly
>> we end up with ((%rdi << 32) >> 32) - 1 which computes to 4
>> but the upper bound should be 5. The GIMPLE debug stmts compute
>> the upper bound as (sizetype)((long)(i_1(D) + 1) - 1)
>
> The << 32 >> 32 is sign extension. And yes, for f1 I don't see why
> DW_OP_GNU_entry_value shouldn't work, i in main is needed for the call to
> f2, so needs to live in some register or memory in that function until the
> second call. For f2 i is needed after the bar call for the a[i + 4] read,
> worst case in form of precomputed i + 4, but that is reversible op.
>
> Jakub
>
