Bug 228161 - [devel/powerpc64-gcc] Please enable --enable-gnu-indirect-function so xtoolchain can build CURRENT on amd64
Summary: [devel/powerpc64-gcc] Please enable --enable-gnu-indirect-function so xtoolch...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexander Kabaev
Keywords: patch
Depends on:
Reported: 2018-05-11 18:02 UTC by Conrad Meyer
Modified: 2018-05-15 00:39 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (kan)

Proposed patch (635 bytes, patch)
2018-05-11 18:05 UTC, Conrad Meyer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Conrad Meyer freebsd_committer 2018-05-11 18:02:56 UTC
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
Comment 1 Conrad Meyer freebsd_committer 2018-05-11 18:05:40 UTC
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.
Comment 2 Ed Maste freebsd_committer 2018-05-11 21:05:55 UTC
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.
Comment 3 Conrad Meyer freebsd_committer 2018-05-11 21:13:27 UTC
(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.
Comment 4 Mark Millard 2018-05-12 18:25:40 UTC
(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.
Comment 5 Conrad Meyer freebsd_committer 2018-05-12 18:39:58 UTC
(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_TARGET=      ${ARCH}-unknown-${OPSYS:tl}${OSREL}

Instead of the attached patch.
Comment 6 Alexander Kabaev freebsd_committer 2018-05-13 00:17:09 UTC
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.
Comment 7 Conrad Meyer freebsd_committer 2018-05-13 00:28:01 UTC
Comment 8 Mark Millard 2018-05-13 00:45:25 UTC
(In reply to Alexander Kabaev from comment #6)

Is this the type of things for which an exp run in appropriate?
Comment 9 Alexander Kabaev freebsd_committer 2018-05-13 00:57:46 UTC
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.
Comment 10 commit-hook freebsd_committer 2018-05-13 21:46:49 UTC
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

  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

Comment 11 Conrad Meyer freebsd_committer 2018-05-13 23:16:02 UTC
Comment 12 Mark Millard 2018-05-14 02:12:05 UTC
(In reply to commit-hook from comment #10)


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.)
Comment 13 Alexander Kabaev freebsd_committer 2018-05-14 02:32:03 UTC
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.