aboutsummaryrefslogtreecommitdiff
path: root/gdb/symtab.h
diff options
context:
space:
mode:
authorCarl Love <cel@linux.ibm.com>2024-01-02 17:46:02 -0500
committerCarl Love <cel@linux.ibm.com>2024-01-02 17:46:02 -0500
commitfe6356def678a93121a68147bdf93b6980bbf75d (patch)
treecb2ff763d9af621b425751841cd6255ee59baa94 /gdb/symtab.h
parent29deb4221d07d2c497183853e6023acb51d49be9 (diff)
downloadgdb-fe6356def678a93121a68147bdf93b6980bbf75d.zip
gdb-fe6356def678a93121a68147bdf93b6980bbf75d.tar.gz
gdb-fe6356def678a93121a68147bdf93b6980bbf75d.tar.bz2
PowerPC and aarch64: Fix reverse stepping failure
When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and gdb.reverse/solib-reverse.exp. The failure happens around the following code: 38 b[1] = shr2(17); /* middle part two */ 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */ 42 shr1 ("message 1\n"); /* shr1 one */ Normal execution: - step from line 38 will land on line 40. - step from line 40 will land on line 42. Reverse execution: - step from line 42 will land on line 40. - step from line 40 will land on line 40. - step from line 40 will land on line 38. The problem here is that line 40 contains two contiguous but distinct PC ranges in the line table, like so: Line 40 - [0x7ec ~ 0x7f4] Line 40 - [0x7f4 ~ 0x7fc] The two distinct ranges are generated because GCC started outputting source column information, which GDB doesn't take into account at the moment. When stepping forward from line 40, we skip both of these ranges and land on line 42. When stepping backward from line 42, we stop at the start PC of the second (or first, going backwards) range of line 40. Since we've reached ecs->event_thread->control.step_range_start, we stop stepping backwards. The above issues were fixed by introducing a new function that looks for adjacent PC ranges for the same line, until we notice a line change. Then we take that as the start PC of the range. The new start PC for the range is used for the control.step_range_start when setting up a step range. The test case gdb.reverse/map-to-same-line.exp is added to test the fix for the above reverse step issues. Patch has been tested on PowerPC, X86 and AArch64 with no regressions.
Diffstat (limited to 'gdb/symtab.h')
-rw-r--r--gdb/symtab.h17
1 files changed, 17 insertions, 0 deletions
diff --git a/gdb/symtab.h b/gdb/symtab.h
index 32e8993..70eeb35 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -38,6 +38,7 @@
#include "gdb-demangle.h"
#include "split-name.h"
#include "frame.h"
+#include <optional>
/* Opaque declarations. */
struct ui_file;
@@ -2367,6 +2368,22 @@ extern struct symtab_and_line find_pc_line (CORE_ADDR, int);
extern struct symtab_and_line find_pc_sect_line (CORE_ADDR,
struct obj_section *, int);
+/* Given PC, and assuming it is part of a range of addresses that is part of
+ a line, go back through the linetable and find the starting PC of that
+ line.
+
+ For example, suppose we have 3 PC ranges for line X:
+
+ Line X - [0x0 - 0x8]
+ Line X - [0x8 - 0x10]
+ Line X - [0x10 - 0x18]
+
+ If we call the function with PC == 0x14, we want to return 0x0, as that is
+ the starting PC of line X, and the ranges are contiguous.
+*/
+
+extern std::optional<CORE_ADDR> find_line_range_start (CORE_ADDR pc);
+
/* Wrapper around find_pc_line to just return the symtab. */
extern struct symtab *find_pc_line_symtab (CORE_ADDR);