aboutsummaryrefslogtreecommitdiff
path: root/gdb/amd64-linux-tdep.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/amd64-linux-tdep.c
parent152d9c48a29685752ce06a0248a3f0f490c5660a (diff)
downloadbinutils-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/amd64-linux-tdep.c')
0 files changed, 0 insertions, 0 deletions