Re: PR27625, powerpc64 gold __tls_get_addr calls
authorAlan Modra <amodra@gmail.com>
Tue, 19 Oct 2021 22:42:48 +0000 (09:12 +1030)
committerAlan Modra <amodra@gmail.com>
Wed, 20 Oct 2021 21:24:27 +0000 (07:54 +1030)
commitc7fdac09d919aaf86d302e6c622de6ee000c1b7c
tree47897b545380188f705f62771049c1d864c05605
parent570bc7936f5aa9299eee20ba3e170b44efd6c98f
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.
gold/powerpc.cc