Like https://svnweb.freebsd.org/ports?view=revision&revision=344030 , please enable ifuncs on the xtoolchain GCC. Thanks! Until it is enabled, xtoolchain cannot build CURRENT on amd64: In file included from /usr/src/sys/amd64/amd64/fpu.c:64:0: /usr/src/sys/amd64/amd64/fpu.c:195:22: error: ifunc is not supported on this target DEFINE_IFUNC(, void, fpusave, (void *), static) ^ ./x86/ifunc.h:55:19: note: in definition of macro 'DEFINE_IFUNC' qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ ^~~~ /usr/src/sys/amd64/amd64/fpu.c:202:22: error: ifunc is not supported on this target DEFINE_IFUNC(, void, fpurestore, (void *), static) ^ ./x86/ifunc.h:55:19: note: in definition of macro 'DEFINE_IFUNC' qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ ^~~~ --- fpu.o --- *** [fpu.o] Error code 1
Created attachment 193286 [details] Proposed patch I do not have a ports bit, so I cannot commit the attached patch. I also have not tested it.
If the issue is that GCC's configure didn't enable ifunc automatically (as opposed to an explicit, if possibly unintentional setting in the port) we should also report this upstream. GCC is incorrect if it believes FreeBSD does not support ifunc.
(In reply to Ed Maste from comment #2) > GCC is incorrect if it believes FreeBSD does not support ifunc. I don't think it's entirely incorrect of GCC — ld.bfd 2.17.50 is still the system linker until the default actually flips to lld, and ld.lld in general only became usable very recently. In comparison GCC6.3 came out in Dec 2016. We didn't support ifuncs in 2016 — that's totally fair. I don't know if GCC-head knows about FreeBSD ifunc support or not, though.
(In reply to Conrad Meyer from comment #3) Various architectures are not supported by lld yet, for example the powerpc families. If I remember right, 32-bit powerpc still uses the ld.bfd 2.17.50 that is in the system in the normal way of building. [I historically experiment with more modern tools and report evidence of problems that I run into.] It is not obvious to me if use of --enable-gnu-indirect-function is appropriate to all architectures in all ways of cross building with devel/*-xtoolchain-gcc vs. not. But the 32-bit powerpc case may not mean much since there is no devel/powerpc-xtoolchain-gcc or devel/powerpc-gcc at this point, just devel/powerpc64-xtoolchain-gcc and devel/powerpc64-gcc . (There is also devel/powerpc64-binutils that I use with clang for powerpc64.) I do not know enough about mips and the like to know if there are analogous points elsewhere or not.
(In reply to Mark Millard from comment #4) Scope can trivially be reduced to amd64 (which is where the only ifunc use is) via something like: @@ -68,6 +69,7 @@ .if ${TARGETARCH} == "amd64" CONFIGURE_TARGET= x86_64-unknown-${OPSYS:tl}${OSREL} +CONFIGURE_ARGS+=--enable-gnu-indirect-function .else CONFIGURE_TARGET= ${ARCH}-unknown-${OPSYS:tl}${OSREL} .endif Instead of the attached patch.
If we enable it for all architectures, what is the harm? It still needs to be used explicitly, so ports have to test for it anyway and if binutils do not work, tests should fail. Ports that make the decision testing compiler only are broken anyway. All of this pure theoretical though, I have no idea what software does. I'll enable flag for all architectures, assuming gcc ports still build and will switch to more fine-grained approach only if necessary.
Thanks!
(In reply to Alexander Kabaev from comment #6) Is this the type of things for which an exp run in appropriate?
exp-run doing what exactly? These are xtoolchain ports that nothing depends on. If someone feel adventurous, one can try to build _and run_ FreeBSD base system on each supported architecture. That someone will certainly NOT be I.
A commit references this bug: Author: kan Date: Sun May 13 21:46:07 UTC 2018 New revision: 469834 URL: https://svnweb.freebsd.org/changeset/ports/469834 Log: Upgrade ext-toolchain GCC ports to GCC 6.4.0 This is the latest supported release in GCC 6.x series. Drop aarch64 support patch - it has been committed upstream. Enable ifunc suppport by default. PR: 228161 Reviewed by: bapt (update part) Differential Revision: https://reviews.freebsd.org/D13602 Changes: head/devel/aarch64-gcc/Makefile head/devel/aarch64-none-elf-gcc/Makefile head/devel/arm-none-eabi-gcc/Makefile head/devel/mips-gcc/Makefile head/devel/mips64-gcc/Makefile head/devel/powerpc64-gcc/Makefile head/devel/powerpc64-gcc/distinfo head/devel/powerpc64-gcc/files/patch-aarch64-support head/devel/powerpc64-gcc/files/patch-gcc_ubsan.c head/devel/sparc64-gcc/Makefile
(In reply to commit-hook from comment #10) Thanks. I did a amd64 -> powerpc64 cross build of -r333594 based on xtoolchain-gcc materials, with the --enable-gnu-indirect-function in place. It built, installed, and booted the old PowerMac G5 so-called "Quad Core" just fine. Side note: The /usr/ports/base/gcc/ is still 6.3.0 based but you may well not be involved with that one. (It is tied to getting a build in place that avoids gcc 4.2.1 and clang/lld on powerpc64, sparc64, and mips, ending up with a fairly modern compiler/toolchain in place via /usr/ports/base/binutils/ and /usr/ports/base/gcc/ based package .txz files. clang and lld are not working sufficiently yet, at least for powerpc64.)
Upgrading base/gcc is probably as easy as bumping distfile version and updating checksums. Technically, bapt@ still owns these, but I can test the patch and commit if he does not object.