I use head on powerpc64, r362833.
Running bc causes a segfault.
Segmentation fault (core dumped)
Starting program: /usr/bin/bc
Program received signal SIGSEGV, Segmentation fault.
0x0000000010068450 in main ()
#0 0x0000000010068450 in main ()
#1 0x0000000010018e80 in _start (argc=<optimized out>, argv=0xfffffbfffe988, env=<optimized out>, obj=<optimized out>, cleanup=<optimized out>, ps_strings=<optimized out>)
Adding se@, who committed bc.
Also adding imp@, who accepted https://reviews.freebsd.org/D19982.
This bug causes Poudriere to segfault during build (because Poudriere uses bc). As such, clusteradm@ must NOT upgrade powerpc64/head systems with new bc until this is fixed, because this will break repo building.
Adding clusteradm@ so that they can keep track of this issue.
(In reply to Piotr Kubaj from comment #3)
To make it clear, do you mean the powerpc64 package builder should stay as it as for now and shouldn't be upgraded?
BTW, package builder's base version is controlled by portmgr team.
(In reply to Li-Wen Hsu from comment #4)
Yes, I meant the host (not Poudriere jails) because this issue directly affects Poudriere.
Poudriere jails can probably be upgraded, just some ports that use bc to build will fail.
I thought portmgr@ controlled only jails, while clusteradm@ managed hosts. Is that not the case?
(In reply to Piotr Kubaj from comment #5)
Thanks for clarification. clusteradm build the base images for different branches and versions for the cluster. portmgr have root on the machines allocated for them, and they decide when and what to install/upgrade is the best.
Created attachment 216180 [details]
Disable -flto on powerpc64
The attached patch fixes the issue for me.
There is probably a bug with LLVM's LTO for PowerPC64 (but, at least on PPC64, it doesn't seem related to floating point incompatibilities, as a comment in the Makefile suggests).
It is probably worth to investigate why LLVM LTO is producing incorrect code, but disabling LTO for gh-bc should be fine while LLVM is not fixed (if this is really the case).
For the record, the code fragment that is crashing is jumping to a pointer to a TOC entry, instead of using the pointer stored at that TOC entry, that correctly points to main().
A commit references this bug:
Date: Fri Jul 3 20:32:54 UTC 2020
New revision: 362914
bc: disable -flto on powerpc64
Previously bc segfaulted at start, on powerpc64.
Submitted by: luporl
Reported by: pkubaj
MFC after: 1 week
^Triage: assign to committer that resolved.