aboutsummaryrefslogtreecommitdiff
path: root/libctf/ctf-serialize.c
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2021-04-28 10:53:00 +0200
committerJan Beulich <jbeulich@suse.com>2021-04-28 10:53:00 +0200
commiteb19308f2d09675dd936960c15603ae749e0f837 (patch)
tree5fba813ce356228e4f3dac2fdcb0963008e002b9 /libctf/ctf-serialize.c
parent6c356992b46da85a3eae0e901538c9d9855508ed (diff)
downloadgdb-eb19308f2d09675dd936960c15603ae749e0f837.zip
gdb-eb19308f2d09675dd936960c15603ae749e0f837.tar.gz
gdb-eb19308f2d09675dd936960c15603ae749e0f837.tar.bz2
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 'libctf/ctf-serialize.c')
0 files changed, 0 insertions, 0 deletions