[Bug gdb/30352] A source line with debug information cannot be “reached” in instruction-level stepping

yangyibiao at nju dot edu.cn sourceware-bugzilla@sourceware.org
Sun Apr 16 14:57:21 GMT 2023


https://sourceware.org/bugzilla/show_bug.cgi?id=30352

--- Comment #4 from Yibiao Yang <yangyibiao at nju dot edu.cn> ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #1)
> > If after reading this you still think it's misleading, you can file an
> > enhancement PR to let users turn off this feature.
> 
> Also, you can look into "set print frame-info " (
> https://sourceware.org/gdb/onlinedocs/gdb/Print-Settings.html#index-set-
> print-frame_002dinfo ).
> 
> For instance, location-and-address makes it more clear when this behavior is
> happening: the line number changes but the pc stays the same.
> 
> Alternatively, you could consider using TUI, with a asm/src layout:
> ...
> (gdb) tui new-layout src-asm src 1 asm 1 status 0 cmd 1
> (gdb) layout src-asm
> ...
> 
> You can see both the current instruction, and the current line, so it's easy
> to see when you're executing an insn in main but the line is in foo.

Thank you very much for the detailed explanation. Yes, I can found that the
instruction is not changed when using source-level stepping for this inlined
function. After reading GDB's default behavior for inlined function you
mentioned, I understand why debugger has such a behavior. However, I was
wondering the GCC side could do better for inlined functions by establishing a
mapping between the inserted copy function body with the orginal function code
when the '-g' flag is enabled. In this way, gdb can display which source code
the instruction belongs to when stepping at instruction level.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Gdb-prs mailing list