[Bug gas/27763] x86-64 RIP-relative address with labels wraps around signed 32-bit integer

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27763

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Jan Beulich <jbeulich@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=eb19308f2d09675dd936960c15603ae749e0f837

commit eb19308f2d09675dd936960c15603ae749e0f837
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 28 10:53:00 2021 +0200

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.