diff options
author | Tom Tromey <tom@tromey.com> | 2023-03-16 14:41:31 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2023-03-17 16:17:43 -0600 |
commit | 48e0f38c30a153855e1adc9dc76614f3f88d686a (patch) | |
tree | fd93b0e93df5852cd5bfcb81e7854fa418234ffb /gdb/jit.c | |
parent | 152d9c48a29685752ce06a0248a3f0f490c5660a (diff) | |
download | binutils-48e0f38c30a153855e1adc9dc76614f3f88d686a.zip binutils-48e0f38c30a153855e1adc9dc76614f3f88d686a.tar.gz binutils-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/jit.c')
-rw-r--r-- | gdb/jit.c | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -491,7 +491,7 @@ jit_symtab_line_mapping_add_impl (struct gdb_symbol_callbacks *cb, stab->linetable->nitems = nlines; for (i = 0; i < nlines; i++) { - stab->linetable->item[i].set_raw_pc ((CORE_ADDR) map[i].pc); + stab->linetable->item[i].set_raw_pc (unrelocated_addr (map[i].pc)); stab->linetable->item[i].line = map[i].line; stab->linetable->item[i].is_stmt = true; } |