Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) (LLVMgold.so and gnu's ld.gold)
Mark Millard
marklmi at yahoo.com
Tue Aug 4 02:56:18 UTC 2020
On 2020-Jul-25, at 13:59, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Jul-8, at 01:28, Stefan Eßer <se at freebsd.org> wrote:
>
>> Am 08.07.20 um 09:01 schrieb Mark Millard:
>>> The following is more informational than anything as far
>>> as I'm concerned. But there may be implications that I'm
>>> unaware of. (I sometimes experiment with toolchain use
>>> to see what the current status is for such use.)
>>>
>>> I attempted to build a system for 32-bit powerpc using clang
>>> and binutils, building head -r363000 ( from -r363000 ). (This
>>> was a cross build, amd64 -> powerpc.) It got a new type of
>>> failure, compared to my past experience:
>>
>> Hi Mark,
>>
>> thank you for the report. I have tested with "make universe" (with
>> default settings) that this version builds on all architectures,
>> but Ed Maste has already disabled -flto for powerpc64, due to run
>> time issues (floating point exception, IIRC).
>>
>> I know that you are actively working on PowerPC and I'd appreciate,
>> if you could provide me with information on which parameters cause
>> breakage and which work for you. The combination of CLANG with LTO
>> and GNU binutils cannot work - CLANG and GCC use incompatible file
>> formats to represent the intermediate object files.
>
> Hmm. It looks a little more complicated than that . . .
>
> Looks like the devel/llvm80 devel/llvm90 and devel/llvm10
> options for powerpc64 include one for:
>
> GOLD=on: Build the LLVM Gold plugin for LTO
>
> That produces a plugin (LLVMgold.so) for use with gnu's
> ld.gold ( from devel/binutils ).
>
> . . .
Ignore those notes. It looks like I greatly misinterpreted. For
example doing some personal software builds with -flto in use
resulted in (using devel/llvm11 as an example context):
(powerpc64 context used)
"/usr/local/llvm11/bin/ld" . . . -plugin /usr/local/llvm11/bin/../lib/LLVMgold.so -plugin-opt=mcpu=ppc64 -plugin-opt=O3 . . .
LLVMgold.so is for the llvm linker to use. I had built
llvm10 with the gold option selected and there is:
# ls -ldT /usr/local/llvm11/bin/../lib/LLVMgold.so
-rwxr-xr-x 1 root wheel 94160 Jul 29 14:50:07 2020 /usr/local/llvm11/bin/../lib/LLVMgold.so
But, for the system clang 10 with -flto involved:
"/usr/bin/ld" . . . -plugin /usr/bin/../lib/LLVMgold.so -plugin-opt=mcpu=ppc64 -plugin-opt=O3 . . .
(yet there is no /usr/bin/../lib/LLVMgold.so present).
And for even the likes of just:
static volatile char big_area[67001] = "This is a test";
int main ()
{
big_area[67000] = '9';
}
commands like ( system clang and devel/llvm10 ):
cc -flto main.c
clang10 -flto main.c
for powerpc64 produce invalid a.out files that do
not even contain a main function when looked at
with the likes of objdump -d --prefix-addresses
and produce an a.out that does:
# ./a.out
Segmentation fault (core dumped)
Or when run inside gdb such builds produce things like:
Starting program: /root/c_tests/a.out
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00000000100412e8 in main ()
#1 0x0000000010010718 in _start (argc=<optimized out>, argv=0xfffffbfffebb8, env=<optimized out>, obj=<optimized out>, cleanup=<optimized out>, ps_strings=<optimized out>)
at /usr/src/lib/csu/powerpc64/crt1_c.c:127
(gdb) disass
Dump of assembler code for function main:
=> 0x00000000100412e8 <+0>: .long 0x0
0x00000000100412ec <+4>: mullhwu r0,r1,r1
0x00000000100412f0 <+8>: .long 0x0
0x00000000100412f4 <+12>: vmsumshm v0,v2,v17,v19
0x00000000100412f8 <+16>: .long 0x0
0x00000000100412fc <+20>: .long 0x0
0x0000000010041300 <+0>: .long 0xfffff
0x0000000010041304 <+4>: stmw r31,-4128(r31)
0x0000000010041308 <+0>: .long 0xfffff
0x000000001004130c <+4>: stmw r31,-5176(r31)
0x0000000010041310 <+0>: .long 0x0
End of assembler dump.
For reference:
# uname -apKU
FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #13 r363590M: Sun Jul 26 20:14:08 PDT 2020 root at FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300102 1300102
# svnlite info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 543890
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 543890
Last Changed Date: 2020-07-31 22:52:17 -0700 (Fri, 31 Jul 2020)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-toolchain
mailing list