From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B6DF33857404; Mon, 21 Mar 2022 19:44:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B6DF33857404 From: "assaiante at diag dot uniroma1.it" To: gdb-prs@sourceware.org Subject: [Bug gdb/28987] New: Outdated value being displayed for variable while DWARF info apparently contains the correct one Date: Mon, 21 Mar 2022 19:44:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 11.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: assaiante at diag dot uniroma1.it X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 19:44:45 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28987 Bug ID: 28987 Summary: Outdated value being displayed for variable while DWARF info apparently contains the correct one Product: gdb Version: 11.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: assaiante at diag dot uniroma1.it Target Milestone: --- In this minimized C example, variable i, defined within the scope of the function foo, has a wrong value displayed upon the call of the function tes= t, which is defined in an external module. To reproduce the issue, the program should be compiled with a recent version of gcc using -O2 and the flag -fno-tree-dce. We believe this may be a bug in gdb since debugging the same executable file in lldb shows us the correct value. We provide an initial analysis below on x64 and some considerations on further tests on a variant= of this code. The following gcc bug report may also be of interest: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105007 $ cat a.c void foo() {=20 int l_3 =3D 5, i =3D 0; for (; i < 8; i++) ; test(l_3, i); } int main() { foo(); } $ cat lib.c #include void test(int l_3, int i) { printf("%d %d", l_3, i); } 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 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 -O2 -g a.c lib.c -o unopt -fno-tree-dce $ gdb -q unopt Reading symbols from unopt... (gdb) b 6 Breakpoint 1 at 0x400520: file a.c, line 6. (gdb) r Starting program: /home/stepping/2/reduce/unopt=20=20 Breakpoint 1, foo () at a.c:6 6 test(l_3, i); (gdb) info loc l_3 =3D 5 i =3D 0 At line 6, the value of i should be 8 since the call to test() is after the= for loop that increments the variable from 0 to 8. Using a different debugger (= we tried lldb) the correct value is shown. ASM: 0000000000400520 : 400520: be 08 00 00 00 mov $0x8,%esi 400525: bf 05 00 00 00 mov $0x5,%edi 40052a: 31 c0 xor %eax,%eax 40052c: e9 0f 00 00 00 jmpq 400540 400531: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 400538: 00 00 00=20 40053b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) DWARF info: 0x00000070: DW_TAG_subprogram=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 DW_AT_external (true) DW_AT_name ("foo") DW_AT_decl_file ("/home/stepping/2/reduce/a.c") DW_AT_decl_line (1) DW_AT_decl_column (0x06) DW_AT_low_pc (0x0000000000400520) DW_AT_high_pc (0x0000000000400531) DW_AT_frame_base (DW_OP_call_frame_cfa) DW_AT_call_all_calls (true) 0x0000008a: DW_TAG_variable=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 DW_AT_name ("l_3") DW_AT_decl_file ("/home/stepping/2/reduce/a.c") DW_AT_decl_line (3) DW_AT_decl_column (0x09) DW_AT_type (0x00000039 "int") DW_AT_const_value (0x05) 0x00000097: DW_TAG_variable=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 DW_AT_name ("i") DW_AT_decl_file ("/home/stepping/2/reduce/a.c") DW_AT_decl_line (3) DW_AT_decl_column (0x12) DW_AT_type (0x00000039 "int") DW_AT_location (0x0000001e:=20=20 [0x0000000000400520, 0x0000000000400520): DW_OP_lit0, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit1, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit2, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit3, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit4, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit5, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit6, DW_OP_stack_value [0x0000000000400520, 0x0000000000400520): DW_OP_lit7, DW_OP_stack_value [0x0000000000400520, 0x0000000000400531): DW_OP_lit8, DW_OP_stack_value) DW_AT_GNU_locviews (0x0000000c) >>From dumped DWARF info, the location of variable i is defined with different ranges, all of them being empty except one. The only non-empty range is [0x0000000000400520, 0x0000000000400531). As we can see from the assembly of function foo, it covers all the function=E2=80=99s instructions and the val= ue associated to it is 8, which can be considered correct as the for loop is optimized out and 8 is directly passed to the test function as a constant. This issue may be related to a possible gcc bug that we found by compiling = this code at -O2 or -O3, resulting in l_3 and i not being visible when debugging= . In the involved tests, we found that providing -fno-tree-dce along with -O2 results in a binary where both variables are visible, but with the i=E2=80= =99s value issue pointed out here. We then found that also disabling inlining at eithe= r O2 or O3 makes both variables appear, but DWARF info may be the issue there si= nce lldb shows i as not available while gdb still reports 0 value. --=20 You are receiving this mail because: You are on the CC list for the bug.=