Date: Mon, 3 Aug 2020 19:56:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Stefan_E=C3=9Fer?= <se@freebsd.org> Cc: svn-src-head@freebsd.org, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-ppc <freebsd-ppc@freebsd.org> Subject: 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) Message-ID: <72B5174F-124F-4259-BDF2-32E4E850A1F8@yahoo.com> In-Reply-To: <8B43A4F4-E44D-40C0-8984-FD0FD43198FE@yahoo.com> References: <64523602-7EFC-4A97-90EA-C776BF2A0AF7.ref@yahoo.com> <64523602-7EFC-4A97-90EA-C776BF2A0AF7@yahoo.com> <d96b12df-cbff-387d-7bf4-bc5b279b10f4@freebsd.org> <8B43A4F4-E44D-40C0-8984-FD0FD43198FE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jul-25, at 13:59, Mark Millard <marklmi@yahoo.com> wrote:
> On 2020-Jul-8, at 01:28, Stefan E=C3=9Fer <se at freebsd.org> wrote:
>=20
>> 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.)
>>>=20
>>> 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:
>>=20
>> Hi Mark,
>>=20
>> 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).
>>=20
>> 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.
>=20
> Hmm. It looks a little more complicated than that . . .
>=20
> Looks like the devel/llvm80 devel/llvm90 and devel/llvm10
> options for powerpc64 include one for:
>=20
> GOLD=3Don: Build the LLVM Gold plugin for LTO
>=20
> That produces a plugin (LLVMgold.so) for use with gnu's
> ld.gold ( from devel/binutils ).
>=20
> . . .
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=3Dmcpu=3Dppc64 =
-plugin-opt=3DO3 . . .
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=3Dmcpu=3Dppc64 -plugin-opt=3DO3 . . .
(yet there is no /usr/bin/../lib/LLVMgold.so present).
And for even the likes of just:
static volatile char big_area[67001] =3D "This is a test";
int main ()
{
big_area[67000] =3D '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=20
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00000000100412e8 in main ()
#1 0x0000000010010718 in _start (argc=3D<optimized out>, =
argv=3D0xfffffbfffebb8, env=3D<optimized out>, obj=3D<optimized out>, =
cleanup=3D<optimized out>, ps_strings=3D<optimized out>)
at /usr/src/lib/csu/powerpc64/crt1_c.c:127
(gdb) disass
Dump of assembler code for function main:
=3D> 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/powe=
rpc.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)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72B5174F-124F-4259-BDF2-32E4E850A1F8>