Bug#803474: src:systemd: Please use the default linker instead of gold on sparc64

[John Paul Adrian Glaubitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/08/2015 11:15 PM, Michael Biebl wrote:
> A quick test-build, where I removed /usr/lib/gold-ld/ 
> /usr/bin/gold /usr/bin/ld.gold
> 
> was successful on amd64. So this approach might work. Instead of
> removing gold on sparc, it might be better though to simply rename
> it to something like gold-experimental or so. So users/devs who
> explicitly want to test the linker could do so easily.

It's also successful on sparc64 and after some more research, I came
to the conclusion that we should, in fact, disable gold on sparc*
completely which I have already done in the unreleased suite. I will
ask Matthias to disable gold on sparc* in the binutils package in
unstable.

> Btw, #790556 is marked as fixed-upstream.

I know. Me and a good friend were involved fixing the issue. However,
this was merely a bug while ...

> issues. The one involving STT-REGISTER is, as you are well aware,
> not fixed upstream.

... this is absolutely non-trivial as it turns out.

To briefly explain the issue as Michael Karcher (who helped debugging
#790556) explained it to me: STT_REGISTER is actually called
STT_SPARC_REGISTER which is a so-called pseudo or dummy symbol in
the ELF object file. This dummy symbol is used to tell the linker
how either of the four global registers %2, %3, %6 or %7 are used
within a certain object file (either not used, for temporary variables
or for a third case which I already forgot). The use case is encoded
into the address field assigned to the symbol in the ELF object file.

At the same time, the symbol is marked as undefined. Now, the problem
is that gold does not support this type of dummy symbol at all and
is actually confused that a symbol is undefined and has a non-zero
address value in the address field at the same time and then writes
just zero into the address field which in turn results in the known
error message since any value other than 2,3 6 or 7 is not allowed:

	Only registers %g[2367] can be declared using STT_REGISTER


At first look it might look trivial to add support for
STT_SPARC_REGISTER in gold to the sparc backend. But the problem is
that these dummy symbols cannot be stored in gold's internal
representation of an ELF object file which means that parts of
the non-architecture-specific code of gold have to be rewritten
which takes a while [1].

To cut a long story short: The gold developers did not implement
a fully spec-compliant SPARC backend meaning that potentially
anything linked with gold on sparc* is broken. Which is why gold
should not be used on sparc* at all for the time being.

We can therefore either close this bug report or reassign it
to binutils, tracking binutils upstream PR target/19019.

Thanks for being stubborn enough and having me do more extensive
research :).

Cheers,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19019#c18

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWP8+VAAoJEHQmOzf1tfkTUFEP/ibASYSiET5MOA/syB0DZPRY
hgN4PZytPXL+hkQrDlYHRRoNp8JurFItbmZo/LlapA9JGYz9TuzDyOk10+l1Pwpi
p4QeOp0b1D0qNvHnqX1PcJuQzugmZfG8PNTc6jmSLYvzJ+hi5UKghrpiQm0G84f8
pcfqHY48FBLe4QPtKsA1awdczP6wMTNGjAGmRnFEuvAhE3c6h7Mg2IZatGr8IBvn
Q+kB0Engd/xMuiYz9blAmS3E7auWNsETuZlumVe4cNqW363fgkkCzRVD1wsFtX5G
cFTSKGLzQ3xNNkneEZxfw9tcxfXMLf0wJgD7lQu+m+DMasM0OJEUH6PlMMnYMF47
DOOZxHw7JQEhSn0DakaadfZU98dEdgRSU63lchQZQw3pp36T9ZsNKSfhPynta28/
nlXRjeIXe82IgLK0+HRoF00dDmNOK3qhKf2cYtn8pWvbrsSdwVzSzCp+C3MbmXqL
a3VeNlr2nK4dFs4s+OnkBcJRlsokQsvYc7a0bqL6OsRUEtE4k+IumB5XV1ANFRSk
6rUbkkKWnGoM7QaPba1K/5QAzpmEX1ID/86hCVC2OIj75cNDNT+gkGUG4d6ZGTab
rhmptO2S3hEKYcGETUpVuz/kkkKNDbC9mvQZ1rBiPKf9s+3qUxq+q7K99nhZ5NMn
iU8jpMlFmr3JCBFA8HV1
=Z05P
-----END PGP SIGNATURE-----