Log snippet: --- all_subdir_libexec --- collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. /usr/local/bin/sparc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.33.1 assertion fail elfxx-sparc.c:763 *** [ld-elf.so.1.full] Error code 1 make[4]: stopped in /usr/home/emaste/src/freebsd/libexec/rtld-elf 1 error Assertion comes from: static void sparc_elf_append_rela (bfd *abfd, asection *s, Elf_Internal_Rela *rel) { const struct elf_backend_data *bed; bfd_byte *loc; bed = get_elf_backend_data (abfd); BFD_ASSERT (s->reloc_count * bed->s->sizeof_rela < s->size); <<<<<< loc = s->contents + (s->reloc_count++ * bed->s->sizeof_rela); bed->s->swap_reloca_out (abfd, rel, loc); }
Created attachment 210506 [details] Patch to fix the port for SPARC64 FreeBSD on SPARC64 (semi-)broke upstream in binutils after the 2.30 release. I've been digging into this for days and finally found the problem: Upstream commit c9098af41e3246586a30f4f0bdb0ee4367e9a5e7 removed old cruft (a.out and coff support) and simplified the targets for gas. The latter was an oversimplification, however, since the newly introduced target matches FreeBSD as well and makes gas behave as it should be on NetBSD. The attached patch makes it possible to cross-build for SPARC64 on AMD64 using the external toolchain (patched binutils 2.33.1 and GCC 9.2). I've also reported the issue on the GNU binutils mailing list.
Can you boot a resulting system using the patch?
I have yet to try booting a system cross-built with this. Around Christmas I built -CURRENT from r356126 (with binutils 2.30) and got a kernel panic during boot. However the machine seemed to hit the same panic, when the code was built natively on SPARC64 (with the old GNU toolchain in base), so it might not be the external one's fault. My plan for the next step is to find a good revision and figure out when -CURRENT broke. However the only SPARC64 machine I have access to right now has 550 MHz, so that even with ccache building takes quite some time (I hope to get a beefier one, though). I'll keep cross-compiling as well and hope to find a working revision earlier by doing that. If anybody has any suggestions on what to try, I'll gladly do.
*** Bug 241374 has been marked as a duplicate of this bug. ***
(In reply to Michael Reim from comment #3) If you really want to try to keep sparc64 viable, I would post the kernel panic and backtrace to the sparc64@ mailing list to see if someone can help debug it. However, FreeBSD/sparc64 doesn't really have enough support in the developer community to be a viable platform in 13 and later. FWIW, the patch to binutils looks correct to me.
I've added a patch for the port at https://reviews.freebsd.org/D23087. I don't have hardware to test, but I'd be willing to look at the kernel panic if you pasted it here or on the mailing list.
A commit references this bug: Author: jhb Date: Thu Jan 9 18:05:54 UTC 2020 New revision: 522533 URL: https://svnweb.freebsd.org/changeset/ports/522533 Log: Fix gas for FreeBSD/sparc64. Since binutils 2.30, gas treated FreeBSD/sparc64 the same as NetBSD and OpenBSD and generated incorrect code as a result. PR: 243119 Submitted by: Michael Reim Reviewed by: bapt (maintainer), emaste Differential Revision: https://reviews.freebsd.org/D23087 Changes: head/devel/binutils/Makefile head/devel/binutils/files/patch-gas-configure.tgt