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)

2020-08-03 Thread Mark Millard via svn-src-head
On 2020-Jul-25, at 13:59, Mark Millard  wrote:

> On 2020-Jul-8, at 01:28, Stefan Eßer  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  0x100412e8 in main ()
#1  0x10010718 in _start (argc=, argv=0xfbfffebb8, 
env=, obj=, cleanup=, 
ps_strings=)
at /usr/src/lib/csu/powerpc64/crt1_c.c:127
(gdb) disass
Dump of assembler code for function main:
=> 0x100412e8 <+0>: .long 0x0
   0x100412ec <+4>: mullhwu r0,r1,r1
   0x100412f0 <+8>: .long 0x0
   0x100412f4 <+12>:vmsumshm v0,v2,v17,v19
   0x100412f8 <+16>:.long 0x0
   0x100412fc <+20>:.long 0x0
   0x10041300 <+0>: .long 0xf
   0x10041304 <+4>: stmwr31,-4128(r31)
   0x10041308 <+0>: .long 0xf
   0x1004130c <+4>: stmwr31,-5176(r31)
   0x10041310 <+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)

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


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)

2020-07-25 Thread Mark Millard via svn-src-head


On 2020-Jul-8, at 01:28, Stefan Eßer  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 ).

The system-clang/llvm materials do not seem to include
LLVMgold.so and so prevent use of that toolchain for
LTO via devel/binutils . (A FreeBSD choice rather than
a llvm* vs. binutils technically-blocking issue?)

devel/binutils builds and installs /usr/local/bin/ld.gold
for both 32-bit powerpc contexts and for powerpc64 contexts.

However, for the 32-bit powerpc context, the devel/llvm*
do not include an option to enable building LLVMgold.so .
I do not know if this is just a ports choice vs. if this
has a technically-blocking issue involved.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"