$ gcc --version gcc (GCC) 13.0.0 20220608 (experimental) $ gdb --version GNU gdb (GDB) 13.0.50.20220608-git $ cat small.c char *pa; char *pb; void access (volatile char *ptr) { *ptr = 'x'; } int main (int argc, char **argv) { char a, b; pa = &a; pb = &b; access (pa); access (pb); return 0; } $ gcc -O2 -g small.c; gdb -q a.out Reading symbols from a.out... (gdb) b main Breakpoint 1 at 0x401020: file small.c, line 10. (gdb) r Starting program: /root/a.out Breakpoint 1, main (argc=1, argv=0x7fffffffe4f8) at small.c:10 10 pa = &a; (gdb) s 13 access (pa); (gdb) bt -frame-info location-and-address #0 0x0000000000401025 in main (argc=1, argv=0x7fffffffe4f8) at small.c:13 (gdb) maint info line-table objfile: /root/a.out ((struct objfile *) 0x20d7c60) compunit_symtab: small.c ((struct compunit_symtab *) 0x216ac40) symtab: /root/small.c ((struct symtab *) 0x216acc0) linetable: ((struct linetable *) 0x21cb060): INDEX LINE ADDRESS IS-STMT PROLOGUE-END 0 7 0x0000000000401020 Y 1 8 0x0000000000401020 Y 2 10 0x0000000000401020 Y 3 10 0x0000000000401020 4 4 0x0000000000401025 5 10 0x000000000040102a 6 11 0x0000000000401031 Y 7 11 0x0000000000401031 8 13 0x000000000040103d Y 9 4 0x000000000040103d Y 10 4 0x000000000040103d Y 11 4 0x000000000040103d 12 14 0x000000000040103d Y 13 4 0x000000000040103d Y 14 4 0x000000000040103d Y 15 17 0x000000000040103d 16 4 0x000000000040103f 17 4 0x0000000000401044 18 16 0x0000000000401044 Y 19 17 0x0000000000401044 20 END 0x0000000000401045 Y 21 4 0x0000000000401140 Y 22 4 0x0000000000401140 Y 23 4 0x0000000000401140 24 4 0x0000000000401143 25 END 0x0000000000401144 Y (gdb) ====================================================================== = As we can find from the line-table, line 4 is only maps to the address of 0x0000000000401025 and the "IS-STMT" for line 13 is "Y"(yes). = However, the backtrace reports that this address of 0x0000000000401025 is at line 13 as "#0 0x0000000000401025 in main (argc=1, argv=0x7fffffffe4f8) at small.c:13". = I was wondering that this might be a gdb issue. ======================================================================
Looks like a bug.
As far as I can tell this is part of gdb's magic to make debugging of inline functions easier to follow. I've different addresses, but I get a similar result: ``` (gdb) s 13 access (pa); (gdb) bt -frame-info location-and-address #0 0x000000013f96253e in main (argc=<optimized out>, argv=<optimized out>) at gdb-29236.c:13 (gdb) maint info line-table gdb-29236.c INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END ... 12 4 0x000000013f96253e 0x000000014000253e ``` And then, I step again: ``` (gdb) s 0x000000013f96253e in access (ptr=<optimized out>) at gdb-29236.c:4 4 void access (volatile char *ptr) { *ptr = 'x'; } (gdb) bt -frame-info location-and-address #0 0x000000013f96253e in access (ptr=<optimized out>) at gdb-29236.c:4 #1 0x000000013f96253e in main (argc=<optimized out>, argv=<optimized out>) at gdb-29236.c:13 ``` The address stays the same, so gdb didn't really step, but just faked this for the user.
The problem is that while cleverly showing 2 different debug states for the same pc (1. call to inlined code, 2. inlined code) we otherwise don't make explicit that we do this, causing user confusion. Using this sort of annotation (not sure about the logic, but works for the example): ... diff --git a/gdb/stack.c b/gdb/stack.c index 4a3e7e4ff00..18291f139d7 100644 --- a/gdb/stack.c +++ b/gdb/stack.c @@ -1353,7 +1353,13 @@ print_frame (struct ui_out *uiout, { annotate_frame_address (); if (pc_p) - print_pc (uiout, gdbarch, frame, pc); + { + int n = frame_inlined_callees (frame); + int total = n + (get_frame_type (frame) == INLINE_FRAME ? 1 : 0); + if (total != 0) + gdb_printf ("VIEWPOINT(%d/%d)@", total - n + 1, total + 1); + print_pc (uiout, gdbarch, frame, pc); + } else uiout->field_string ("addr", "<unavailable>", metadata_style.style ()); ... we get: ... $ gdb -q -batch -iex "set trace-commands on" a.out \ -ex start \ -ex step \ -ex "bt -frame-info location-and-address" \ -ex step \ -ex "bt -frame-info location-and-address" +start Temporary breakpoint 1 at 0x410080: file small.c, line 10. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0xffffffffe928) at small.c:10 10 pa = &a; +step 13 access (pa); +bt -frame-info location-and-address #0 VIEWPOINT(1/2)@0x000000000041008c in main (argc=<optimized out>, argv=0xffffffffe928) at small.c:13 +step VIEWPOINT(2/2)@0x000000000041008c in access (ptr=<optimized out>) at small.c:4 4 void access (volatile char *ptr) { *ptr = 'x'; } +bt -frame-info location-and-address #0 VIEWPOINT(2/2)@0x000000000041008c in access (ptr=<optimized out>) at small.c:4 #1 VIEWPOINT(1/2)@0x000000000041008c in main (argc=<optimized out>, argv=0xffffffffe928) at small.c:13 ... shows in an in-your-face fashion that tricks are being played with the address. [ We're going to need something similar for location views, the same confusion is likely to show up once we start supporting that. ] Changing into an enhancement, updating $subject.