Re: Quick status update on sparc64
On Tue, Nov 10, 2015 at 4:10 PM, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> Over the past weeks, we have made substantial progress in catching up
> with the build queue and the number of packages which are up-to-date
> in the sparc64 port are now over 8400 which means we have built more
> than 700 packages since I started my thread with the subjet
> "Resurrecting Debian on SPARC" on September, 15 2015.
>
> One important factor is an additional buildd machine, a Sun T2000,
> which is hosted by Harka Gyozo at the University of Pécs in Pécs,
> Hungary. Thanks, Harka! Helge Deller, the main porter and buildd
> maintainer, for Debian's hppa (PA-RISC) port, helped in setting
> up a total of five buildd instances on Harka's machine (andi1
> through andi5) which helped to use the machine more efficiently.
> Plus, Helge is now registered as a wanna-build (Debian's package
> build database) which means he can trigger binNMUs and rebuilds
> on sparc64 as well. In order for Helge to be able to solve
> problems with the buildds, he has also been granted access to
> the sparc64 buildds which helps reducing my workload. Thanks, Helge!
>
> Furthermore, I managed to fix several packages that were failing to
> build by completely disabling the gold linker on sparc64. As further
> research has shown, gold currently creates defect binaries due to
> the fact that it does not fully implement the specification for
> ELF binaries on SPARC.
>
> To be more precise, it lacks support for the so-called dummy symbol
> "STT_SPARC_REGISTER" which the linker uses to define how either of the
> four global CPU registers %[2367] are used. Since gold does not
> understand that STT_SPARC_REGISTER is a dummy symbol and not to
> be associated with an actual offset address, it sets the address
> field associated with the symbol to zero (while only 2, 3, 6 or
> 7 are valid values) which produces a defect object file which
> later produces the known error message on consecutive linker
> runs [1]:
>
> Only registers %g[2367] can be declared using STT_REGISTER
>
> The problem with this bug is that currently gold's internal
> representation of ELF objects has no way to accommodate these
> dummy symbols. This means, that gold needs additional work
> on its generic, non-target-specific code which will naturally
> take a bit longer.
Good work, John!
Out of curiosity, the STT_REGISTER issue is caused by ABI and is
not Linux-specific, so Solaris and *BSD have it too, right?
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
Reply to: