mbox series

[v3,0/3] Improve debugging of optimized code

Message ID AS8P193MB12855E0F9D40695E201381F8E4DF2@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM
Headers
Series Improve debugging of optimized code |

Message

Bernd Edlinger July 5, 2024, 9:15 a.m. UTC 
  I've rebased and re-tested the following patches
which are trying to improve the debug experience of
optimized gcc code.  This work was previously posted
quite some time ago here:
https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html

These patches improve the debug experience with optimized
gcc code significantly, as can be seen by the test cases.
The problem is that there are cases where an inline function
has line table entries at the end of the inline subrange,
and it is unclear by the dwarf-5 debug info if these line
table entries belong to the called inline function or to
the calling outer function, while there are at least some
corner cases where by stepping into these lines e.g. the
return value might be inspected.  Also the call stack is
often displayed wrong because the line table entries
do not match with the block structure i.e. are obviously
not in the correct function.

Therefore this patch series tries to improve the issue by
introducing a heuristic, that marks some of the line table
entries that happen to be at the exact end of an inline
function range as weak.  This new line table flag can be
used to avoid to step into the inline function when a
step over was requested, and display the line belonging
to the correct function in the callstack.

I'm sorry, that this solution has quite some complexity,
but I promise it is worth it.  Please give this patch
a try and look for yourself how the debug experience is
improved in the test cases, and certainly also a number of
other programs, especially with C++, where inline functions
are pretty much used everywhere.

v3: minor update to fix regressions in gdb.cp/empty-inline.exp

This update fixes only one test case, that turned out, not to
work properly with arm and aarch64 targets (many thanks to Linaro
for reporting this to me).  The reason was that the call stack
looks slightly different when the trap is on a statement boundary
or not.  So the test expectation was changed to ignore that bit.
Additionally the test case was failing on riscv simulator targets
because assignment to NULL is not enough to cause an exception
on a simulator.  However assigning to (char*)-1 triggers always
an exception.


Bernd Edlinger (3):
  Fix handling of DW_AT_entry_pc of inlined subroutines
  Introduce a new line table flag is_weak
  Fix range end handling of inlined subroutines

 gdb/block.c                                   |  15 +-
 gdb/buildsym.c                                | 106 ++++++++--
 gdb/buildsym.h                                |   3 +
 gdb/dwarf2/read.c                             |  89 +++-----
 gdb/infcmd.c                                  |   3 +-
 gdb/infrun.c                                  |  30 ++-
 gdb/jit.c                                     |   1 +
 gdb/symmisc.c                                 |   6 +-
 gdb/symtab.c                                  |  17 +-
 gdb/symtab.h                                  |   5 +
 gdb/testsuite/gdb.base/empty-inline.c         |  39 ++++
 gdb/testsuite/gdb.base/empty-inline.exp       |  56 +++++
 gdb/testsuite/gdb.cp/empty-inline.cc          |  33 +++
 gdb/testsuite/gdb.cp/empty-inline.exp         |  50 +++++
 gdb/testsuite/gdb.cp/step-and-next-inline.cc  |   6 +-
 gdb/testsuite/gdb.cp/step-and-next-inline.exp | 194 +++++++-----------
 gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp  |   2 +-
 gdb/xcoffread.c                               |   1 +
 18 files changed, 443 insertions(+), 213 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/empty-inline.c
 create mode 100644 gdb/testsuite/gdb.base/empty-inline.exp
 create mode 100644 gdb/testsuite/gdb.cp/empty-inline.cc
 create mode 100644 gdb/testsuite/gdb.cp/empty-inline.exp