https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104938
Bug ID: 104938
Summary: Possibly wrong location definition in DWARF with
-ftree-cpp at -Og only
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, variable l_3, which is initialized at line 5, is
associated to DWARF symbols having a possibly wrong location definition. This
causes the variable to not be available during debugging, for instance at line
6, until line 11 is reached. We observe the bug at -Og with the cause likely
being -ftree-ccp, while with other optimizations levels the variable is
correctly available at the lines where gdb can step (line 6 with -O1/O2/O3/Os,
also line 8 with -O1/Os). Please find below a detailed analysis for -Og on x64.
$ cat a.c
char a;
int b;
void foo(int *d) { a = 0; }
int main() {
int *l_3 = &b;
int **e = &l_3;
f:
if (a)
goto f;
*e = l_3;
foo(*e);
}
GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) start
Temporary breakpoint 1 at 0x40048e: file a.c, line 8.
Starting program: /home/stepping/132/reduce/opt
Temporary breakpoint 1, main () at a.c:8
8 if (a)
(gdb) info locals
l_3 = <optimized out>
e = <optimized out>
(gdb) n
11 foo(*e);
(gdb) info locals
l_3 = 0x60102c <b>
e = <optimized out>
By dumping the DWARF info, we can see how the location associated to the
variable is defined with a range that does not include the instruction
associated to line 8, where the variable's value is not available despite the
original program has assigned (and, incidentally, also used) it by then.
ASM:
000000000040048e <main>:
40048e: 80 3d 9b 0b 20 00 00 cmpb $0x0,0x200b9b(%rip) #
601030 <a>
400495: 75 f7 jne 40048e <main>
400497: bf 2c 10 60 00 mov $0x60102c,%edi
40049c: e8 e5 ff ff ff callq 400486 <c>
4004a1: b8 00 00 00 00 mov $0x0,%eax
4004a6: c3 retq
4004a7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
4004ae: 00 00
DWARF info:
0x00000084: DW_TAG_variable
DW_AT_name ("l_3")
DW_AT_decl_file ("/home/stepping/132/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x08)
DW_AT_type (0x000000cc "int*")
DW_AT_location (0x0000000e:
[0x0000000000400497, 0x00000000004004a1): DW_OP_addr
0x60102c, DW_OP_stack_value)
DW_AT_GNU_locviews (0x0000000c)
Through some testing we found out that the optimization flag that introduces
the bug is likely -ftree-ccp. If we add -fno-tree-ccp to the compilation
command line used above, variable l_3 appears in the current frame with its
value correctly available at line 8. The location of the variable appears now
to be correctly defined with the range including the cmp instruction that
corresponds to line 8 according to the line number table in DWARF info.
ASM with -fno-tree-ccp:
40048e: 48 83 ec 10 sub $0x10,%rsp
400492: 48 c7 44 24 08 2c 10 movq $0x60102c,0x8(%rsp)
400499: 60 00
40049b: 80 3d 8e 0b 20 00 00 cmpb $0x0,0x200b8e(%rip) #
601030 <a>
4004a2: 75 f7 jne 40049b <main+0xd>
4004a4: bf 2c 10 60 00 mov $0x60102c,%edi
4004a9: e8 d8 ff ff ff callq 400486 <c>
4004ae: b8 00 00 00 00 mov $0x0,%eax
4004b3: 48 83 c4 10 add $0x10,%rsp
4004b7: c3 retq
4004b8: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
4004bf: 00
DWARF info with -fno-tree-ccp:
0x00000093: DW_TAG_variable
DW_AT_name ("e")
DW_AT_decl_file ("/home/stepping/132/reduce/a.c")
DW_AT_decl_line (6)
DW_AT_decl_column (0x09)
DW_AT_type (0x000000d4 "int**")
DW_AT_location (0x0000000e:
[0x000000000040049b, 0x00000000004004b8): DW_OP_fbreg -16,
DW_OP_stack_value)
DW_AT_GNU_locviews (0x0000000c)
We also tested the program against older versions of gcc (6, 7, 8, 9, 10, 11)
and the issue is present in all of them.
