Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) (LLVMgold.so and gnu's ld.gold)

On 2020-Jul-25, at 13:59, Mark Millard <[email protected]> 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@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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"