This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][debug] Handle references to skipped params in remap_ssa_name
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.
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