diff options
author | Jan Beulich <jbeulich@suse.com> | 2021-04-28 10:53:00 +0200 |
---|---|---|
committer | Jan Beulich <jbeulich@suse.com> | 2021-04-28 10:53:00 +0200 |
commit | eb19308f2d09675dd936960c15603ae749e0f837 (patch) | |
tree | 5fba813ce356228e4f3dac2fdcb0963008e002b9 /gdb/main.c | |
parent | 6c356992b46da85a3eae0e901538c9d9855508ed (diff) | |
download | binutils-gdb-eb19308f2d09675dd936960c15603ae749e0f837.tar.gz |
x86: honor signedness of PC-relative relocations
PR gas/27763
While the comment in output_jump() was basically correct prior to the
introduction of 64-bit mode, both that and the not-JMP-like behavior of
XBEGIN require adjustments: Branches with 32-bit displacement do not
wrap at 4G in 64-bit mode, and XBEGIN with 16-bit operand size doesn't
wrap at 64k. Similarly %rip-relative addressing doesn't wrap at 4G.
The new testcase points out that for PE/COFF object_64bit didn't get
set so far, preventing in particular the check at the end of
md_convert_frag() to take effect.
For Mach-O the new testcase fails (bogusly), in that only the first two
of the expected errors get raised. Since for Mach-O many testcases
already fail, and since an x86_64-darwin target can't even be configured
for, I didn't think I need to bother.
Note that there are further issues in this area, in particular for
branches with operand size overrides. Such branches, which truncate
%rip / %eip, can't be correctly expressed with ordinary PC-relative
relocations. It's not really clear what to do with them - perhaps the
best we can do is to carry through all associated relocations, leaving
it to the linker (or even loader) to decide (once the final address
layout is known). Same perhaps goes for relocations associated with
32-bit addressing in 64-bit mode.
Diffstat (limited to 'gdb/main.c')
0 files changed, 0 insertions, 0 deletions