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

[Michael Biebl]

Control: reassign -1 binutils
Control: retitle -1 please remove gold linker on sparc*

Hi Adrian,

thanks for your detailed explanation.
Given those findings, I'm going to re-assign this bug to binutils (CCing
the complete message so doko has some more context), asking for the
removal of the gold linker on sparc.

Regards,
Michael

Am 08.11.2015 um 23:41 schrieb John Paul Adrian Glaubitz:
> 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


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20151112/a28e82ae/attachment-0002.sig>