From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 715CE3858D34; Sun, 3 May 2020 10:32:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 715CE3858D34 From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug cli/25911] New: Show column when stepping through line Date: Sun, 03 May 2020 10:32:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: cli X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW 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: Sun, 03 May 2020 10:32:19 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25911 Bug ID: 25911 Summary: Show column when stepping through line Product: gdb Version: HEAD Status: NEW Severity: enhancement Priority: P2 Component: cli Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- I. Consider the following test-case: ... $ cat -n stmts-on-line.c=20 1 int 2 main (void) 3 { 4 int a =3D 4; 5 6 a =3D 5; a =3D 6; a =3D 7; 7 8 return 0; 9 } ... II. Compiled with gcc 7.5.0 and debug info: ... $ gcc -g stmts-on-line.c=20 ... We can step through the instructions on line 6 using stepi: ... $ gdb a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x40049b: file stmts-on-line.c, line 4. Starting program: a.out=20 Temporary breakpoint 1, main () at stmts-on-line.c:4 4 int a =3D 4; (gdb) s 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 0x00000000004004a9 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 0x00000000004004b0 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 8 return 0; ... and can see progress through the line number and instruction addresses. That works as follows. The instructions are at addresses: ... 40049b: c7 45 fc 04 00 00 00 movl $0x4,-0x4(%rbp) 4004a2: c7 45 fc 05 00 00 00 movl $0x5,-0x4(%rbp) 4004a9: c7 45 fc 06 00 00 00 movl $0x6,-0x4(%rbp) 4004b0: c7 45 fc 07 00 00 00 movl $0x7,-0x4(%rbp) 4004b7: b8 00 00 00 00 mov $0x0,%eax ... and the line number info table looks like: ... [0x00000125] Special opcode 62: advance Address by 4 to 0x40049b and Lin= e by 1 to 4 [0x00000126] Special opcode 105: advance Address by 7 to 0x4004a2 and Li= ne by 2 to 6 [0x00000127] Advance PC by constant 17 to 0x4004b3 [0x00000128] Special opcode 63: advance Address by 4 to 0x4004b7 and Lin= e by 2 to 8 ... So, put in DWARF standard terms, there are "recommended breakpoint location= s" at 0x40049b, 0x4004a2 and 0x4004b7. When we're stopped at such a location,= the line without address is shown. When we're stopped at an instruction which is not such a location, the line with address is shown (4004a9, 4004b0). III. Now consider the same test-case, compiled with gcc 10.0.1 and debug info: ... $ gcc-10 -g stmts-on-line.c=20 ... Now when stepping through the instructions on line 6 using stepi: ... $ gdb a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x400496: file stmts-on-line.c, line 4. Starting program: /data/gdb_versions/devel/a.out=20 Temporary breakpoint 1, main () at stmts-on-line.c:4 4 int a =3D 4; (gdb) s 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 8 return 0; ... we don't see progress, we seem to be stuck at line 6. In this case, the instructions are at addresses: ... 400496: c7 45 fc 04 00 00 00 movl $0x4,-0x4(%rbp) 40049d: c7 45 fc 05 00 00 00 movl $0x5,-0x4(%rbp) 4004a4: c7 45 fc 06 00 00 00 movl $0x6,-0x4(%rbp) 4004ab: c7 45 fc 07 00 00 00 movl $0x7,-0x4(%rbp) 4004b2: b8 00 00 00 00 mov $0x0,%eax ... and the line number info table looks like: ... [0x00000129] Special opcode 62: advance Address by 4 to 0x400496 and Lin= e by 1 to 4 [0x0000012a] Set column to 5 [0x0000012c] Special opcode 105: advance Address by 7 to 0x40049d and Li= ne by 2 to 6 [0x0000012d] Set column to 12 [0x0000012f] Special opcode 103: advance Address by 7 to 0x4004a4 and Li= ne by 0 to 6 [0x00000130] Set column to 19 [0x00000132] Special opcode 103: advance Address by 7 to 0x4004ab and Li= ne by 0 to 6 [0x00000133] Set column to 10 [0x00000135] Special opcode 105: advance Address by 7 to 0x4004b2 and Li= ne by ... Now all the instructions are also breakpoint locations, which explains why = we don't see addresses. IV. It would be good if gdb can somehow show progress here, perhaps through something like: ... (gdb) s 6 a =3D 5; a =3D 6; a =3D 7; (gdb) si 6 a =3D 5; a =3D 6; a =3D 7; ^ (gdb) si 6 a =3D 5; a =3D 6; a =3D 7; ^ (gdb) si 8 return 0; ... --=20 You are receiving this mail because: You are on the CC list for the bug.=