bug-binutils
[Top][All Lists]
Advanced

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

[Bug gold/27625] powerpc64: gold erroneously rejects linking code that c


From: cvs-commit at gcc dot gnu.org
Subject: [Bug gold/27625] powerpc64: gold erroneously rejects linking code that calls __tls_get_addr
Date: Wed, 20 Oct 2021 21:30:30 +0000

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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Alan Modra <amodra@sourceware.org>:

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

commit c7fdac09d919aaf86d302e6c622de6ee000c1b7c
Author: Alan Modra <amodra@gmail.com>
Date:   Wed Oct 20 09:12:48 2021 +1030

    Re: PR27625, powerpc64 gold __tls_get_addr calls

    My previous PR27625 patch had a problem or two.  For one, the error
    "__tls_get_addr call lacks marker reloc" on processing some calls
    before hitting a call without markers typically isn't seen.  Instead a
    gold assertion fails.  Either way it would be a hard error, which
    triggers on a file contained in libphobos.a when running the gcc
    testsuite.  A warning isn't even appropriate since the call involved
    is one built by hand without any of the arg setup relocations that
    might result in linker optimisation.

    So this patch reverts most of commit 0af4fcc25dd5, instead entirely
    ignoring the problem of mis-optimising old-style __tls_get_addr calls
    without marker relocs.  We can't handle them gracefully without
    another pass over relocations before decisions are made about GOT
    entries in Scan::global or Scan::local.  That seems too costly, just
    to link object files from 2009.  What's more, there doesn't seem to be
    any way to allow the libphobos explicit __tls_get_addr call, but not
    old TLS sequences without marker relocs.  Examining instructions
    before the __tls_get_addr call is out of the question: program flow
    might reach the call via a branch.  Putting an R_PPC64_TLSGD marker
    with zero sym on the call might be a solution, but current linkers
    will then merrily optimise away the call!

            PR gold/27625
            * powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
            and tls_opt_error_ variables and accessors.  Remove all uses.

-- 
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]