aboutsummaryrefslogtreecommitdiff
path: root/gdb/record-btrace.c
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2023-03-16 14:41:31 -0600
committerTom Tromey <tom@tromey.com>2023-03-17 16:17:43 -0600
commit48e0f38c30a153855e1adc9dc76614f3f88d686a (patch)
treefd93b0e93df5852cd5bfcb81e7854fa418234ffb /gdb/record-btrace.c
parent152d9c48a29685752ce06a0248a3f0f490c5660a (diff)
downloadgdb-48e0f38c30a153855e1adc9dc76614f3f88d686a.zip
gdb-48e0f38c30a153855e1adc9dc76614f3f88d686a.tar.gz
gdb-48e0f38c30a153855e1adc9dc76614f3f88d686a.tar.bz2
Fix line table regression
Simon pointed out a line table regression, and after a couple of false starts, I was able to reproduce it by hand using his instructions. The bug is that most of the code in do_mixed_source_and_assembly uses unrelocated addresses, but one spot does: pc = low; ... after the text offset has been removed. This patch fixes the problem by introducing a new type to represent unrelocated addresses in the line table. This prevents this sort of bug to some degree (it's still possible to manipulate a CORE_ADDR in a bad way, this is unavoidable). However, this did let the compiler flag a few spots in that function, and now it's not possible to compare an unrelocated address from a line table with an ordinary CORE_ADDR. Regression tested on x86-64 Fedora 36, though note this setup never reproduced the bug in the first place. I also tested it by hand on the disasm-optim test program.
Diffstat (limited to 'gdb/record-btrace.c')
-rw-r--r--gdb/record-btrace.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
index 3e71c6c..2d88e4d 100644
--- a/gdb/record-btrace.c
+++ b/gdb/record-btrace.c
@@ -724,7 +724,8 @@ btrace_find_line_range (CORE_ADDR pc)
return btrace_mk_line_range (symtab, 0, 0);
struct objfile *objfile = symtab->compunit ()->objfile ();
- pc -= objfile->text_section_offset ();
+ unrelocated_addr unrel_pc
+ = unrelocated_addr (pc - objfile->text_section_offset ());
range = btrace_mk_line_range (symtab, 0, 0);
for (i = 0; i < nlines - 1; i++)
@@ -737,7 +738,7 @@ btrace_find_line_range (CORE_ADDR pc)
possibly adding more line numbers to the range. At the time this
change was made I was unsure how to test this so chose to go with
maintaining the existing experience. */
- if ((lines[i].raw_pc () == pc) && (lines[i].line != 0)
+ if (lines[i].raw_pc () == unrel_pc && lines[i].line != 0
&& lines[i].is_stmt)
range = btrace_line_range_add (range, lines[i].line);
}