bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/26659] x86_64 pe relocation truncated to fit: R_X86_64_PC32 agai


From: cvs-commit at gcc dot gnu.org
Subject: [Bug ld/26659] x86_64 pe relocation truncated to fit: R_X86_64_PC32 against undefined symbol
Date: Thu, 01 Apr 2021 17:07:56 +0000

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

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The binutils-2_36-branch branch has been updated by Tamar Christina
<tnfchris@sourceware.org>:

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

commit 0ff9fad8bf790eebb21a1c1ee378f1c2dd1971af
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Thu Apr 1 17:10:38 2021 +0100

    PE/Windows x86_64: Fix weak undef symbols after image base change

    The change in PR19011 changed the image load address from being in the
lower
    32-bit address space to the higher 64-bit address space.

    However when you have a weak undef symbol which stays undef at the end of
    linking the linker has to resolve this (Windows loader does not support
undef
    symbols).  As such typically these would resolve to 0.

    The relocation used for these weak symbols are the normal 32-bit PC_REL
call
    relocs.  So when doing the overflow check LD checks if the distance between
the
    symbol and the call is within range.  However now that the load address is
    > 32-bits and the symbol val is 0 this overflow check will always fail.

    As such the linker gives a bogus error.  This patch makes the linker not
emit
    the overflow failure but chooses to still let the check be performed (as
it's
    mid-end code).

    One down side of this is that it does break the common convention that the
call
    be to sym at 0x0. i.e. before you'd get

          401015:   74 05                   je     40101c
          401017:   e8 e4 ef bf ff          callq  0

    and now you get

       140001015:   74 05                   je     14000101c
       140001017:   e8 e4 ef ff bf          call   100000000

    since the call is PC_REL there's no way to get the range large enough to
    resolve to 0.  As such I have chosen to leave it as the furthest simple
range
    that we can still represent.

    By only ignoring the error we leave the symbol value itself to still be 0
    such that the if(<symbol>) checks still work correctly.

    bfd/ChangeLog:

    2021-04-01  Tamar Christina  <tamar.christina@arm.com>

            PR ld/26659
            * cofflink.c (_bfd_coff_generic_relocate_section): Ignore overflow.

    ld/ChangeLog:

    2021-04-01  Tamar Christina  <tamar.christina@arm.com>

            PR ld/26659
            * testsuite/ld-pe/pe.exp: Add test.
            * testsuite/ld-pe/pr26659-weak-undef-sym.d: New test.
            * testsuite/ld-pe/pr26659-weak-undef-sym.s: New test.

    (cherry picked from commit 74edb473c9ecf5e2053ecf8e429ee608feafb9e1)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]