From owner-freebsd-ppc@freebsd.org Sun Nov 27 00:41:09 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C369C4B54E for ; Sun, 27 Nov 2016 00:41:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5180D81 for ; Sun, 27 Nov 2016 00:41:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11378 invoked from network); 27 Nov 2016 00:41:47 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Nov 2016 00:41:47 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 26 Nov 2016 19:40:53 -0500 (EST) Received: (qmail 19983 invoked from network); 27 Nov 2016 00:40:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Nov 2016 00:40:52 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 16258EC7ED9; Sat, 26 Nov 2016 16:41:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them. From: Mark Millard In-Reply-To: <82B4883E-250C-4D93-A139-7949665C1B77@dsl-only.net> Date: Sat, 26 Nov 2016 16:41:06 -0800 Cc: Nathan Whitehorn , Dimitry Andric , Justin Hibbits , Ed Maste Content-Transfer-Encoding: quoted-printable Message-Id: <871B0604-B8C8-41B3-A6E5-13DFCE048128@dsl-only.net> References: <82B4883E-250C-4D93-A139-7949665C1B77@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 00:41:09 -0000 [Summary: Looking around with gdb at fsck_ufs I found two __floatdidf = routines with different code. df has the same.] On 2016-Nov-26, at 3:39 PM, Mark Millard wrote: > I updated to head -r309197 (with a work around for -r309144 breaking = the build). >=20 > This was on amd64, then used it to try to cross buildworld using clang = 3.9.0 for > TARGET_ARCH=3Dpowerpc . The build completed. (I've been using clang = 3.8.0 this way > for a long time.) >=20 > [The kernel here was cross built via gcc 4.2.1, as has been my normal = procedure. > The kernel still has my "red zone for signal delivery" hack that was a = workaround > for clang 3.8.0 stack-handling ABI violations.] >=20 > Booting, however, had problems because of fsck_ufs getting signal 11 = and ended up > initially in single user mode. >=20 > Exiting single user did finish the boot. But "df -m" core dumps. (I've = not > explored much else.) >=20 > Turns out that both fsck_ufs and "df -m" fail in the same routine for = a SIGSEGV: > __floatdidf >=20 >=20 > The details. . . >=20 > First the boot and fsck_ufs: >=20 >> Copyright (c) 1992-2016 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT #9 r309179M: Sat Nov 26 12:53:11 PST 2016 >> = markmi@FreeBSDx64:/usr/obj/powerpcvtsc_clang_gcc421_kernel/powerpc.powerpc= /usr/src/sys/GENERICvtsc-NODBG powerpc >> gcc version 4.2.1 20070831 patched [FreeBSD] >> cpu0: IBM PowerPC 970MP revision 1.1, 18446744071914.91 MHz >> cpu0: Features dc000000 >> cpu0: HID0 1511081 >> real memory =3D 2118565888 (2020 MB) >> avail memory =3D 2014863360 (1921 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> . . . >> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]... >> . . . >> pid 53 (fsck_ufs), uid 0: exited on signal 11 >=20 >=20 > Manually running fsck later gets a segmentation fault core file in = /var/crash/ > and I used this too see a point of failure (__floatdidf): >=20 >> # fsck / >> ** /dev/ufs/FBSDG4Srootfs (NO WRITE) >> ** Last Mounted on / >> ** Root file system >> ** Phase 1 - Check Blocks and Sizes >> INCORRECT BLOCK COUNT I=3D11538459 (8 should be 0) >> CORRECT? no >>=20 >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> LINK COUNT FILE I=3D10016041 OWNER=3Doperator MODE=3D100400 >> SIZE=3D4096 MTIME=3DNov 26 14:44 2016 COUNT 2 SHOULD BE 1 >> ADJUST? no >>=20 >> LINK COUNT FILE I=3D10016049 OWNER=3Doperator MODE=3D100400 >> SIZE=3D4096 MTIME=3DNov 26 14:55 2016 COUNT 2 SHOULD BE 1 >> ADJUST? no >>=20 >> LINK COUNT FILE I=3D10016089 OWNER=3Doperator MODE=3D100400 >> SIZE=3D4096 MTIME=3DNov 26 15:00 2016 COUNT 2 SHOULD BE 1 >> ADJUST? no >>=20 >> UNREF FILE I=3D11538459 OWNER=3Droot MODE=3D100600 >> SIZE=3D0 MTIME=3DNov 26 15:11 2016=20 >> RECONNECT? no >>=20 >>=20 >> CLEAR? no >>=20 >> ** Phase 5 - Check Cyl groups >> FREE BLK COUNT(S) WRONG IN SUPERBLK >> SALVAGE? no >>=20 >> SUMMARY INFORMATION BAD >> SALVAGE? no >>=20 >> BLK(S) MISSING IN BIT MAPS >> SALVAGE? no >>=20 >> fsck: /dev/ufs/FBSDG4Srootfs: Segmentation fault >=20 >=20 >> # gdb fsck_ufs /var/crash/fsck_ufs.1129.core=20 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and = you are >> welcome to change it and/or distribute copies of it under certain = conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for = details. >> This GDB was configured as "powerpc-marcel-freebsd"... >> Core was generated by `fsck_ufs /dev/ufs/FBSDG4Srootfs'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /lib/libufs.so.6...Reading symbols from = /usr/lib/debug//lib/libufs.so.6.debug...done. >> done. >> Loaded symbols for /lib/libufs.so.6 >> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >> done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. >> done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x0181b024 in __floatdidf () >> (gdb) bt >> #0 0x0181b024 in __floatdidf () >> #1 0x0180a8e0 in main (argc=3D, argv=3D) at /usr/src/sbin/fsck_ffs/main.c:519 >> #2 0x01801664 in _start () >> #3 0x418303a0 in .text () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >=20 > main.c's line 519 is part of: >=20 >> printf("(%ju frags, %ju blocks, %.1f%% fragmentation)\n", >> (uintmax_t)n_ffree, (uintmax_t)n_bfree, >> n_ffree * 100.0 / sblock.fs_dsize); >=20 >=20 >=20 > As for "df -m" --it failed in __floatdidf as well: >=20 >> # gdb df /var/crash/df.1056.core = = GNU gdb 6.1.1 = [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and = you are >> welcome to change it and/or distribute copies of it under certain = conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for = details. >> This GDB was configured as "powerpc-marcel-freebsd"... >> Core was generated by `df -m'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /lib/libxo.so.0...Reading symbols from = /usr/lib/debug//lib/libxo.so.0.debug...done. >> done. >> Loaded symbols for /lib/libxo.so.0 >> Reading symbols from /lib/libutil.so.9...Reading symbols from = /usr/lib/debug//lib/libutil.so.9.debug...done. >> done. >> Loaded symbols for /lib/libutil.so.9 >> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >> done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. >> done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x01802a18 in __floatdidf () >> (gdb) bt >> #0 0x01802a18 in __floatdidf () >> #1 0x01802538 in prtstat (sfsp=3D0x41e24000, mwp=3D0xffffd930) at = /usr/src/bin/df/df.c:503 >> #2 0x01801df0 in main (argc=3D, argv=3D) at /usr/src/bin/df/df.c:308 >> #3 0x01800cdc in _start () >> #4 0x418153a0 in .text () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >=20 > df.c's line 503 was part of: >=20 >> xo_emit(" {:used-percent/%5.0f}{U:%%}", >> availblks =3D=3D 0 ? 100.0 : (double)used / = (double)availblks * 100.0); >=20 >=20 >=20 > Context details: >=20 >> # head = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap_worl= d-amd64-host-2016-11-26:11:38:36=20 >> Script started on Sat Nov 26 11:38:36 2016 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-ho= st WITH_META_MODE=3Dyes = MAKEOBJDIRPREFIX=3D/usr/obj/powerpcvtsc_clang_world make -j 5 buildworld >> --- buildworld --- >=20 > . . . >=20 >=20 >> # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host >> TO_TYPE=3Dpowerpc >> # >> KERNCONF=3DGENERICvtsc-NODBG >> TARGET=3D${TO_TYPE} >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> # lldb requires missing atomic 8-byte operations for powerpc (non-64) >> WITHOUT_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >=20 >=20 >> # more ~/src.configs/make.conf=20 >> CFLAGS.gcc+=3D -v Looking around in gdb there seem to be two __floatdidf routines with = differing code. First showing the one that was used and failed: (gdb) x/50i 0x0181afc0 . . . 0x181afcc <__floatdidf>: mflr r0 0x181afd0 <__floatdidf+4>: stw r0,4(r1) 0x181afd4 <__floatdidf+8>: stwu r1,-32(r1) 0x181afd8 <__floatdidf+12>: stw r31,28(r1) 0x181afdc <__floatdidf+16>: stw r30,24(r1) 0x181afe0 <__floatdidf+20>: bl 0x182e96c <.got+20> 0x181afe4 <__floatdidf+24>: mr r31,r1 0x181afe8 <__floatdidf+28>: xoris r3,r3,32768 0x181afec <__floatdidf+32>: lis r5,17200 0x181aff0 <__floatdidf+36>: mflr r30 0x181aff4 <__floatdidf+40>: stw r3,12(r31) 0x181aff8 <__floatdidf+44>: stw r5,8(r31) 0x181affc <__floatdidf+48>: lwz r3,-16(r30) 0x181b000 <__floatdidf+52>: lwz r6,-20(r30) 0x181b004 <__floatdidf+56>: lfd f1,8(r31) 0x181b008 <__floatdidf+60>: stw r4,20(r31) 0x181b00c <__floatdidf+64>: stw r5,16(r31) 0x181b010 <__floatdidf+68>: lfd f13,16(r31) 0x181b014 <__floatdidf+72>: lwz r0,36(r1) 0x181b018 <__floatdidf+76>: lwz r31,28(r1) 0x181b01c <__floatdidf+80>: lwz r30,24(r1) 0x181b020 <__floatdidf+84>: lfs f2,0(r3) 0x181b024 <__floatdidf+88>: lwz r3,-12(r30) 0x181b028 <__floatdidf+92>: lfs f0,0(r6) 0x181b02c <__floatdidf+96>: lfs f12,0(r3) 0x181b030 <__floatdidf+100>: fsub f0,f1,f0 0x181b034 <__floatdidf+104>: fmul f0,f0,f2 0x181b038 <__floatdidf+108>: fadd f0,f0,f12 0x181b03c <__floatdidf+112>: fadd f1,f13,f0 0x181b040 <__floatdidf+116>: addi r1,r1,32 0x181b044 <__floatdidf+120>: mtlr r0 0x181b048 <__floatdidf+124>: blr . . . Then showing the one that was not used that I found: (gdb) disass __floatdidf Dump of assembler code for function __floatdidf: 0x4199fc8c <__floatdidf+0>: mflr r0 0x4199fc90 <__floatdidf+4>: stw r0,4(r1) 0x4199fc94 <__floatdidf+8>: stwu r1,-32(r1) 0x4199fc98 <__floatdidf+12>: stw r31,28(r1) 0x4199fc9c <__floatdidf+16>: stw r30,24(r1) 0x4199fca0 <__floatdidf+20>: mr r31,r1 0x4199fca4 <__floatdidf+24>: srawi r5,r3,31 0x4199fca8 <__floatdidf+28>: bl 0x41a0a288 <.got+14428> 0x4199fcac <__floatdidf+32>: cmpwi r3,0 0x4199fcb0 <__floatdidf+36>: addc r6,r4,r5 0x4199fcb4 <__floatdidf+40>: adde r6,r3,r5 0x4199fcb8 <__floatdidf+44>: lis r3,17200 0x4199fcbc <__floatdidf+48>: xor r5,r6,r5 0x4199fcc0 <__floatdidf+52>: mflr r30 0x4199fcc4 <__floatdidf+56>: bge- 0x4199fccc <__floatdidf+64> 0x4199fcc8 <__floatdidf+60>: neg r4,r4 0x4199fccc <__floatdidf+64>: lwz r12,-3124(r30) 0x4199fcd0 <__floatdidf+68>: stw r5,20(r31) 0x4199fcd4 <__floatdidf+72>: stw r4,12(r31) 0x4199fcd8 <__floatdidf+76>: lwz r4,-3120(r30) 0x4199fcdc <__floatdidf+80>: stw r3,16(r31) 0x4199fce0 <__floatdidf+84>: stw r3,8(r31) 0x4199fce4 <__floatdidf+88>: lfd f1,16(r31) 0x4199fce8 <__floatdidf+92>: lfd f3,8(r31) 0x4199fcec <__floatdidf+96>: lfs f0,0(r12) 0x4199fcf0 <__floatdidf+100>: lfs f2,0(r4) 0x4199fcf4 <__floatdidf+104>: fsub f1,f1,f0 0x4199fcf8 <__floatdidf+108>: fsub f0,f3,f0 0x4199fcfc <__floatdidf+112>: fmul f1,f1,f2 0x4199fd00 <__floatdidf+116>: fadd f1,f0,f1 0x4199fd04 <__floatdidf+120>: bge- 0x4199fd0c <__floatdidf+128> 0x4199fd08 <__floatdidf+124>: fneg f1,f1 0x4199fd0c <__floatdidf+128>: lwz r0,36(r1) 0x4199fd10 <__floatdidf+132>: lwz r31,28(r1) 0x4199fd14 <__floatdidf+136>: lwz r30,24(r1) 0x4199fd18 <__floatdidf+140>: addi r1,r1,32 0x4199fd1c <__floatdidf+144>: mtlr r0 0x4199fd20 <__floatdidf+148>: blr End of assembler dump. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Nov 27 03:47:50 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96070C56EFD for ; Sun, 27 Nov 2016 03:47:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-36.reflexion.net [208.70.210.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B2CDB0D for ; Sun, 27 Nov 2016 03:47:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26497 invoked from network); 27 Nov 2016 03:47:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Nov 2016 03:47:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 26 Nov 2016 22:47:50 -0500 (EST) Received: (qmail 9995 invoked from network); 27 Nov 2016 03:47:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Nov 2016 03:47:49 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8D27DEC7ED9; Sat, 26 Nov 2016 19:47:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them. From: Mark Millard In-Reply-To: <871B0604-B8C8-41B3-A6E5-13DFCE048128@dsl-only.net> Date: Sat, 26 Nov 2016 19:47:41 -0800 Cc: Dimitry Andric , Ed Maste Content-Transfer-Encoding: quoted-printable Message-Id: <145D4383-9552-46FD-937C-B9BB8FC84597@dsl-only.net> References: <82B4883E-250C-4D93-A139-7949665C1B77@dsl-only.net> <871B0604-B8C8-41B3-A6E5-13DFCE048128@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 03:47:50 -0000 [Short top post of where floatdidf definitions seem to be for = TARGET_ARCH=3Dpowerpc.] libcompiler_rt , libc , and libgcc each seem to be places with floatdidf definitions: # grep floatdidf = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap_worl= d-amd64-host-2016-11-26:11:38:36 Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libcompiler_r= t/floatdidf.o Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdid= f.o Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdid= f.pico Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/gnu/lib/libgcc/_f= loatdidf.pico Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libcompiler_r= t/floatdidf.po Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdid= f.po For .o: just libcompiler_rt and libc For .po: just libcompiler_rt and libc For .pico: just libgcc and libc Only libc is common to all 3 types of files. But the libc copy is not used by fsck_ufs or df. (The larger address routine is from /lib/libc.so.7 and the smaller one from the "local exec file".) I've no clue if this sort of thing is unique to powerpc or not. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-26, at 4:41 PM, Mark Millard wrote: > [Summary: Looking around with gdb at fsck_ufs I found two __floatdidf = routines > with different code. df has the same.] >=20 > On 2016-Nov-26, at 3:39 PM, Mark Millard = wrote: >=20 >> I updated to head -r309197 (with a work around for -r309144 breaking = the build). >>=20 >> This was on amd64, then used it to try to cross buildworld using = clang 3.9.0 for >> TARGET_ARCH=3Dpowerpc . The build completed. (I've been using clang = 3.8.0 this way >> for a long time.) >>=20 >> [The kernel here was cross built via gcc 4.2.1, as has been my normal = procedure. >> The kernel still has my "red zone for signal delivery" hack that was = a workaround >> for clang 3.8.0 stack-handling ABI violations.] >>=20 >> Booting, however, had problems because of fsck_ufs getting signal 11 = and ended up >> initially in single user mode. >>=20 >> Exiting single user did finish the boot. But "df -m" core dumps. = (I've not >> explored much else.) >>=20 >> Turns out that both fsck_ufs and "df -m" fail in the same routine for = a SIGSEGV: >> __floatdidf >>=20 >>=20 >> The details. . . >>=20 >> First the boot and fsck_ufs: >>=20 >>> Copyright (c) 1992-2016 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>> The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 12.0-CURRENT #9 r309179M: Sat Nov 26 12:53:11 PST 2016 >>> = markmi@FreeBSDx64:/usr/obj/powerpcvtsc_clang_gcc421_kernel/powerpc.powerpc= /usr/src/sys/GENERICvtsc-NODBG powerpc >>> gcc version 4.2.1 20070831 patched [FreeBSD] >>> cpu0: IBM PowerPC 970MP revision 1.1, 18446744071914.91 MHz >>> cpu0: Features dc000000 >>> cpu0: HID0 1511081 >>> real memory =3D 2118565888 (2020 MB) >>> avail memory =3D 2014863360 (1921 MB) >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> . . . >>> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs = [rw,noatime]... >>> . . . >>> pid 53 (fsck_ufs), uid 0: exited on signal 11 >>=20 >>=20 >> Manually running fsck later gets a segmentation fault core file in = /var/crash/ >> and I used this too see a point of failure (__floatdidf): >>=20 >>> # fsck / >>> ** /dev/ufs/FBSDG4Srootfs (NO WRITE) >>> ** Last Mounted on / >>> ** Root file system >>> ** Phase 1 - Check Blocks and Sizes >>> INCORRECT BLOCK COUNT I=3D11538459 (8 should be 0) >>> CORRECT? no >>>=20 >>> ** Phase 2 - Check Pathnames >>> ** Phase 3 - Check Connectivity >>> ** Phase 4 - Check Reference Counts >>> LINK COUNT FILE I=3D10016041 OWNER=3Doperator MODE=3D100400 >>> SIZE=3D4096 MTIME=3DNov 26 14:44 2016 COUNT 2 SHOULD BE 1 >>> ADJUST? no >>>=20 >>> LINK COUNT FILE I=3D10016049 OWNER=3Doperator MODE=3D100400 >>> SIZE=3D4096 MTIME=3DNov 26 14:55 2016 COUNT 2 SHOULD BE 1 >>> ADJUST? no >>>=20 >>> LINK COUNT FILE I=3D10016089 OWNER=3Doperator MODE=3D100400 >>> SIZE=3D4096 MTIME=3DNov 26 15:00 2016 COUNT 2 SHOULD BE 1 >>> ADJUST? no >>>=20 >>> UNREF FILE I=3D11538459 OWNER=3Droot MODE=3D100600 >>> SIZE=3D0 MTIME=3DNov 26 15:11 2016=20 >>> RECONNECT? no >>>=20 >>>=20 >>> CLEAR? no >>>=20 >>> ** Phase 5 - Check Cyl groups >>> FREE BLK COUNT(S) WRONG IN SUPERBLK >>> SALVAGE? no >>>=20 >>> SUMMARY INFORMATION BAD >>> SALVAGE? no >>>=20 >>> BLK(S) MISSING IN BIT MAPS >>> SALVAGE? no >>>=20 >>> fsck: /dev/ufs/FBSDG4Srootfs: Segmentation fault >>=20 >>=20 >>> # gdb fsck_ufs /var/crash/fsck_ufs.1129.core=20 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and = you are >>> welcome to change it and/or distribute copies of it under certain = conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for = details. >>> This GDB was configured as "powerpc-marcel-freebsd"... >>> Core was generated by `fsck_ufs /dev/ufs/FBSDG4Srootfs'. >>> Program terminated with signal 11, Segmentation fault. >>> Reading symbols from /lib/libufs.so.6...Reading symbols from = /usr/lib/debug//lib/libufs.so.6.debug...done. >>> done. >>> Loaded symbols for /lib/libufs.so.6 >>> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >>> done. >>> Loaded symbols for /lib/libc.so.7 >>> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. >>> done. >>> Loaded symbols for /libexec/ld-elf.so.1 >>> #0 0x0181b024 in __floatdidf () >>> (gdb) bt >>> #0 0x0181b024 in __floatdidf () >>> #1 0x0180a8e0 in main (argc=3D, argv=3D) at /usr/src/sbin/fsck_ffs/main.c:519 >>> #2 0x01801664 in _start () >>> #3 0x418303a0 in .text () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >>=20 >> main.c's line 519 is part of: >>=20 >>> printf("(%ju frags, %ju blocks, %.1f%% fragmentation)\n", >>> (uintmax_t)n_ffree, (uintmax_t)n_bfree, >>> n_ffree * 100.0 / sblock.fs_dsize); >>=20 >>=20 >>=20 >> As for "df -m" --it failed in __floatdidf as well: >>=20 >>> # gdb df /var/crash/df.1056.core = = GNU gdb 6.1.1 = [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and = you are >>> welcome to change it and/or distribute copies of it under certain = conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for = details. >>> This GDB was configured as "powerpc-marcel-freebsd"... >>> Core was generated by `df -m'. >>> Program terminated with signal 11, Segmentation fault. >>> Reading symbols from /lib/libxo.so.0...Reading symbols from = /usr/lib/debug//lib/libxo.so.0.debug...done. >>> done. >>> Loaded symbols for /lib/libxo.so.0 >>> Reading symbols from /lib/libutil.so.9...Reading symbols from = /usr/lib/debug//lib/libutil.so.9.debug...done. >>> done. >>> Loaded symbols for /lib/libutil.so.9 >>> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >>> done. >>> Loaded symbols for /lib/libc.so.7 >>> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. >>> done. >>> Loaded symbols for /libexec/ld-elf.so.1 >>> #0 0x01802a18 in __floatdidf () >>> (gdb) bt >>> #0 0x01802a18 in __floatdidf () >>> #1 0x01802538 in prtstat (sfsp=3D0x41e24000, mwp=3D0xffffd930) at = /usr/src/bin/df/df.c:503 >>> #2 0x01801df0 in main (argc=3D, argv=3D) at /usr/src/bin/df/df.c:308 >>> #3 0x01800cdc in _start () >>> #4 0x418153a0 in .text () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >>=20 >> df.c's line 503 was part of: >>=20 >>> xo_emit(" {:used-percent/%5.0f}{U:%%}", >>> availblks =3D=3D 0 ? 100.0 : (double)used / = (double)availblks * 100.0); >>=20 >>=20 >>=20 >> Context details: >>=20 >>> # head = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap_worl= d-amd64-host-2016-11-26:11:38:36=20 >>> Script started on Sat Nov 26 11:38:36 2016 >>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-ho= st WITH_META_MODE=3Dyes = MAKEOBJDIRPREFIX=3D/usr/obj/powerpcvtsc_clang_world make -j 5 buildworld >>> --- buildworld --- >>=20 >> . . . >>=20 >>=20 >>> # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host >>> TO_TYPE=3Dpowerpc >>> # >>> KERNCONF=3DGENERICvtsc-NODBG >>> TARGET=3D${TO_TYPE} >>> .if ${.MAKE.LEVEL} =3D=3D 0 >>> TARGET_ARCH=3D${TO_TYPE} >>> .export TARGET_ARCH >>> .endif >>> # >>> WITH_CROSS_COMPILER=3D >>> WITHOUT_SYSTEM_COMPILER=3D >>> # >>> WITH_LIBCPLUSPLUS=3D >>> WITH_BINUTILS_BOOTSTRAP=3D >>> WITH_CLANG_BOOTSTRAP=3D >>> WITH_CLANG=3D >>> WITH_CLANG_IS_CC=3D >>> WITH_CLANG_FULL=3D >>> WITH_CLANG_EXTRAS=3D >>> # lldb requires missing atomic 8-byte operations for powerpc = (non-64) >>> WITHOUT_LLDB=3D >>> # >>> WITH_BOOT=3D >>> WITHOUT_LIB32=3D >>> # >>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >>> WITHOUT_GCC_BOOTSTRAP=3D >>> WITHOUT_GCC=3D >>> WITHOUT_GCC_IS_CC=3D >>> WITHOUT_GNUCXX=3D >>> # >>> NO_WERROR=3D >>> #WERROR=3D >>> MALLOC_PRODUCTION=3D >>> # >>> WITH_DEBUG_FILES=3D >>=20 >>=20 >>> # more ~/src.configs/make.conf=20 >>> CFLAGS.gcc+=3D -v >=20 > Looking around in gdb there seem to be two __floatdidf routines with = differing code. >=20 > First showing the one that was used and failed: >=20 > (gdb) x/50i 0x0181afc0 > . . . > 0x181afcc <__floatdidf>: mflr r0 > 0x181afd0 <__floatdidf+4>: stw r0,4(r1) > 0x181afd4 <__floatdidf+8>: stwu r1,-32(r1) > 0x181afd8 <__floatdidf+12>: stw r31,28(r1) > 0x181afdc <__floatdidf+16>: stw r30,24(r1) > 0x181afe0 <__floatdidf+20>: bl 0x182e96c <.got+20> > 0x181afe4 <__floatdidf+24>: mr r31,r1 > 0x181afe8 <__floatdidf+28>: xoris r3,r3,32768 > 0x181afec <__floatdidf+32>: lis r5,17200 > 0x181aff0 <__floatdidf+36>: mflr r30 > 0x181aff4 <__floatdidf+40>: stw r3,12(r31) > 0x181aff8 <__floatdidf+44>: stw r5,8(r31) > 0x181affc <__floatdidf+48>: lwz r3,-16(r30) > 0x181b000 <__floatdidf+52>: lwz r6,-20(r30) > 0x181b004 <__floatdidf+56>: lfd f1,8(r31) > 0x181b008 <__floatdidf+60>: stw r4,20(r31) > 0x181b00c <__floatdidf+64>: stw r5,16(r31) > 0x181b010 <__floatdidf+68>: lfd f13,16(r31) > 0x181b014 <__floatdidf+72>: lwz r0,36(r1) > 0x181b018 <__floatdidf+76>: lwz r31,28(r1) > 0x181b01c <__floatdidf+80>: lwz r30,24(r1) > 0x181b020 <__floatdidf+84>: lfs f2,0(r3) > 0x181b024 <__floatdidf+88>: lwz r3,-12(r30) > 0x181b028 <__floatdidf+92>: lfs f0,0(r6) > 0x181b02c <__floatdidf+96>: lfs f12,0(r3) > 0x181b030 <__floatdidf+100>: fsub f0,f1,f0 > 0x181b034 <__floatdidf+104>: fmul f0,f0,f2 > 0x181b038 <__floatdidf+108>: fadd f0,f0,f12 > 0x181b03c <__floatdidf+112>: fadd f1,f13,f0 > 0x181b040 <__floatdidf+116>: addi r1,r1,32 > 0x181b044 <__floatdidf+120>: mtlr r0 > 0x181b048 <__floatdidf+124>: blr > . . . >=20 > Then showing the one that was not used that I found: >=20 > (gdb) disass __floatdidf > Dump of assembler code for function __floatdidf: > 0x4199fc8c <__floatdidf+0>: mflr r0 > 0x4199fc90 <__floatdidf+4>: stw r0,4(r1) > 0x4199fc94 <__floatdidf+8>: stwu r1,-32(r1) > 0x4199fc98 <__floatdidf+12>: stw r31,28(r1) > 0x4199fc9c <__floatdidf+16>: stw r30,24(r1) > 0x4199fca0 <__floatdidf+20>: mr r31,r1 > 0x4199fca4 <__floatdidf+24>: srawi r5,r3,31 > 0x4199fca8 <__floatdidf+28>: bl 0x41a0a288 <.got+14428> > 0x4199fcac <__floatdidf+32>: cmpwi r3,0 > 0x4199fcb0 <__floatdidf+36>: addc r6,r4,r5 > 0x4199fcb4 <__floatdidf+40>: adde r6,r3,r5 > 0x4199fcb8 <__floatdidf+44>: lis r3,17200 > 0x4199fcbc <__floatdidf+48>: xor r5,r6,r5 > 0x4199fcc0 <__floatdidf+52>: mflr r30 > 0x4199fcc4 <__floatdidf+56>: bge- 0x4199fccc <__floatdidf+64> > 0x4199fcc8 <__floatdidf+60>: neg r4,r4 > 0x4199fccc <__floatdidf+64>: lwz r12,-3124(r30) > 0x4199fcd0 <__floatdidf+68>: stw r5,20(r31) > 0x4199fcd4 <__floatdidf+72>: stw r4,12(r31) > 0x4199fcd8 <__floatdidf+76>: lwz r4,-3120(r30) > 0x4199fcdc <__floatdidf+80>: stw r3,16(r31) > 0x4199fce0 <__floatdidf+84>: stw r3,8(r31) > 0x4199fce4 <__floatdidf+88>: lfd f1,16(r31) > 0x4199fce8 <__floatdidf+92>: lfd f3,8(r31) > 0x4199fcec <__floatdidf+96>: lfs f0,0(r12) > 0x4199fcf0 <__floatdidf+100>: lfs f2,0(r4) > 0x4199fcf4 <__floatdidf+104>: fsub f1,f1,f0 > 0x4199fcf8 <__floatdidf+108>: fsub f0,f3,f0 > 0x4199fcfc <__floatdidf+112>: fmul f1,f1,f2 > 0x4199fd00 <__floatdidf+116>: fadd f1,f0,f1 > 0x4199fd04 <__floatdidf+120>: bge- 0x4199fd0c <__floatdidf+128> > 0x4199fd08 <__floatdidf+124>: fneg f1,f1 > 0x4199fd0c <__floatdidf+128>: lwz r0,36(r1) > 0x4199fd10 <__floatdidf+132>: lwz r31,28(r1) > 0x4199fd14 <__floatdidf+136>: lwz r30,24(r1) > 0x4199fd18 <__floatdidf+140>: addi r1,r1,32 > 0x4199fd1c <__floatdidf+144>: mtlr r0 > 0x4199fd20 <__floatdidf+148>: blr > End of assembler dump. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Nov 27 09:31:41 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE893C5842A for ; Sun, 27 Nov 2016 09:31:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-29.reflexion.net [208.70.210.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2936BCA for ; Sun, 27 Nov 2016 09:31:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21500 invoked from network); 27 Nov 2016 09:31:26 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Nov 2016 09:31:26 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 27 Nov 2016 04:31:25 -0500 (EST) Received: (qmail 14349 invoked from network); 27 Nov 2016 09:31:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Nov 2016 09:31:24 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EBD17EC8854; Sun, 27 Nov 2016 01:31:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them. [Code generation error involved.] From: Mark Millard In-Reply-To: <145D4383-9552-46FD-937C-B9BB8FC84597@dsl-only.net> Date: Sun, 27 Nov 2016 01:31:38 -0800 Cc: Dimitry Andric , Nathan Whitehorn , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <3021C59B-D0F5-4725-8119-AF11F005E00A@dsl-only.net> References: <82B4883E-250C-4D93-A139-7949665C1B77@dsl-only.net> <871B0604-B8C8-41B3-A6E5-13DFCE048128@dsl-only.net> <145D4383-9552-46FD-937C-B9BB8FC84597@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 09:31:42 -0000 [This adds notes about a code generation error for r30 handling in what FreeBSD's clang 3.9.0 generated for TARGET_ARCH=3Dpowerpc.] On 2016-Nov-26, at 7:47 PM, Mark Millard wrote: > [Short top post of where floatdidf definitions seem to be for = TARGET_ARCH=3Dpowerpc.] >=20 > libcompiler_rt , libc , and libgcc each seem to be places with > floatdidf definitions: >=20 > # grep floatdidf = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap_worl= d-amd64-host-2016-11-26:11:38:36 > Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libcompiler_r= t/floatdidf.o > Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdid= f.o > Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdid= f.pico > Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/gnu/lib/libgcc/_f= loatdidf.pico > Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libcompiler_r= t/floatdidf.po > Building = /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdid= f.po >=20 > For .o: just libcompiler_rt and libc > For .po: just libcompiler_rt and libc > For .pico: just libgcc and libc >=20 > Only libc is common to all 3 types of files. But the libc copy is > not used by fsck_ufs or df. (The larger address routine is from > /lib/libc.so.7 and the smaller one from the "local exec file".) >=20 > I've no clue if this sort of thing is unique to powerpc or not. Independent of the above potential issue I've added a new comment to = llvm's 26519 about the code generated for compiler_rt's __floatdidf being = wrong: it misuses r30. . . Unfortunately there are problems handling use of r30, at least when = floating point is involved. The used code from the compliler_rt __floatdidf seems to be just wrong = in part of its use of r30. The below initially uses the "df -m" example failure = and its code. At first is saves r30 on the stack as part of the function preamble: Dump of assembler code for function __floatdidf: 0x018029b8 <__floatdidf+0>: mflr r0 0x018029bc <__floatdidf+4>: stw r0,4(r1) 0x018029c0 <__floatdidf+8>: stwu r1,-32(r1) 0x018029c4 <__floatdidf+12>: stw r31,28(r1) 0x018029c8 <__floatdidf+16>: stw r30,24(r1) Later it uses r30 for other things. Then it restores it from the stack: 0x01802a08 <__floatdidf+80>: lwz r30,24(r1) What it does with r30 next effectively makes r30 a parameter to the = routine and not just saved/restored: 0x01802a10 <__floatdidf+88>: lwz r3,-8(r30) In the above the r30 from the caller's context is being used as the base = for accessing memory and putting that memory content in r3. What it does next with r3 is one of the points where SIGSEGV is = happening: For "df -m" r3 ends up being 0 and the following fails. 0x01802a18 <__floatdidf+96>: lfs f12,0(r3) In the fsck_ufs example it is the same sort of thing but r30 happens to = be initially 0 so it fails at an earlier stage. Again there is the preamble that saves r30: 0x0181afcc <__floatdidf+0>: mflr r0 0x0181afd0 <__floatdidf+4>: stw r0,4(r1) 0x0181afd4 <__floatdidf+8>: stwu r1,-32(r1) 0x0181afd8 <__floatdidf+12>: stw r31,28(r1) 0x0181afdc <__floatdidf+16>: stw r30,24(r1) Later it uses r30 for other things. Then it restores it from the stack: 0x0181b01c <__floatdidf+80>: lwz r30,24(r1) What it does with r30 next effectively makes r30 a parameter to the = routine and not just saved/restored: 0x0181b024 <__floatdidf+88>: lwz r3,-12(r30) Again: In the above the r30 from the caller's context is being used as = the base for accessing memory and putting that memory content in r3. But this time it turns out that r30 is 0 and the above also fails. If the code had gotten that far it would have done the same thing with = r3 that "df -m" did in its failure: 0x0181b02c <__floatdidf+96>: lfs f12,0(r3) For reference compiler-rt/lib/builtins/floatdidf.c has: COMPILER_RT_ABI double __floatdidf(di_int a) { static const double twop52 =3D 4503599627370496.0; // 0x1.0p52 static const double twop32 =3D 4294967296.0; // 0x1.0p32 union { int64_t x; double d; } low =3D { .d =3D twop52 }; const double high =3D (int32_t)(a >> 32) * twop32; low.x |=3D a & INT64_C(0x00000000ffffffff); const double result =3D (high - twop52) + low.d; return result; } and the matching assembler code for the fsck_ufs example is (from gdb): =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-26, at 4:41 PM, Mark Millard wrote: > [Summary: Looking around with gdb at fsck_ufs I found two __floatdidf = routines > with different code. df has the same.] >=20 > On 2016-Nov-26, at 3:39 PM, Mark Millard = wrote: >=20 >> I updated to head -r309197 (with a work around for -r309144 breaking = the build). >>=20 >> This was on amd64, then used it to try to cross buildworld using = clang 3.9.0 for >> TARGET_ARCH=3Dpowerpc . The build completed. (I've been using clang = 3.8.0 this way >> for a long time.) >>=20 >> [The kernel here was cross built via gcc 4.2.1, as has been my normal = procedure. >> The kernel still has my "red zone for signal delivery" hack that was = a workaround >> for clang 3.8.0 stack-handling ABI violations.] >>=20 >> Booting, however, had problems because of fsck_ufs getting signal 11 = and ended up >> initially in single user mode. >>=20 >> Exiting single user did finish the boot. But "df -m" core dumps. = (I've not >> explored much else.) >>=20 >> Turns out that both fsck_ufs and "df -m" fail in the same routine for = a SIGSEGV: >> __floatdidf >>=20 >>=20 >> The details. . . >>=20 >> First the boot and fsck_ufs: >>=20 >>> Copyright (c) 1992-2016 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>> The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 12.0-CURRENT #9 r309179M: Sat Nov 26 12:53:11 PST 2016 >>> = markmi@FreeBSDx64:/usr/obj/powerpcvtsc_clang_gcc421_kernel/powerpc.powerpc= /usr/src/sys/GENERICvtsc-NODBG powerpc >>> gcc version 4.2.1 20070831 patched [FreeBSD] >>> cpu0: IBM PowerPC 970MP revision 1.1, 18446744071914.91 MHz >>> cpu0: Features dc000000 >>> cpu0: HID0 1511081 >>> real memory =3D 2118565888 (2020 MB) >>> avail memory =3D 2014863360 (1921 MB) >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> . . . >>> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs = [rw,noatime]... >>> . . . >>> pid 53 (fsck_ufs), uid 0: exited on signal 11 >>=20 >>=20 >> Manually running fsck later gets a segmentation fault core file in = /var/crash/ >> and I used this too see a point of failure (__floatdidf): >>=20 >>> # fsck / >>> ** /dev/ufs/FBSDG4Srootfs (NO WRITE) >>> ** Last Mounted on / >>> ** Root file system >>> ** Phase 1 - Check Blocks and Sizes >>> INCORRECT BLOCK COUNT I=3D11538459 (8 should be 0) >>> CORRECT? no >>>=20 >>> ** Phase 2 - Check Pathnames >>> ** Phase 3 - Check Connectivity >>> ** Phase 4 - Check Reference Counts >>> LINK COUNT FILE I=3D10016041 OWNER=3Doperator MODE=3D100400 >>> SIZE=3D4096 MTIME=3DNov 26 14:44 2016 COUNT 2 SHOULD BE 1 >>> ADJUST? no >>>=20 >>> LINK COUNT FILE I=3D10016049 OWNER=3Doperator MODE=3D100400 >>> SIZE=3D4096 MTIME=3DNov 26 14:55 2016 COUNT 2 SHOULD BE 1 >>> ADJUST? no >>>=20 >>> LINK COUNT FILE I=3D10016089 OWNER=3Doperator MODE=3D100400 >>> SIZE=3D4096 MTIME=3DNov 26 15:00 2016 COUNT 2 SHOULD BE 1 >>> ADJUST? no >>>=20 >>> UNREF FILE I=3D11538459 OWNER=3Droot MODE=3D100600 >>> SIZE=3D0 MTIME=3DNov 26 15:11 2016=20 >>> RECONNECT? no >>>=20 >>>=20 >>> CLEAR? no >>>=20 >>> ** Phase 5 - Check Cyl groups >>> FREE BLK COUNT(S) WRONG IN SUPERBLK >>> SALVAGE? no >>>=20 >>> SUMMARY INFORMATION BAD >>> SALVAGE? no >>>=20 >>> BLK(S) MISSING IN BIT MAPS >>> SALVAGE? no >>>=20 >>> fsck: /dev/ufs/FBSDG4Srootfs: Segmentation fault >>=20 >>=20 >>> # gdb fsck_ufs /var/crash/fsck_ufs.1129.core=20 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and = you are >>> welcome to change it and/or distribute copies of it under certain = conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for = details. >>> This GDB was configured as "powerpc-marcel-freebsd"... >>> Core was generated by `fsck_ufs /dev/ufs/FBSDG4Srootfs'. >>> Program terminated with signal 11, Segmentation fault. >>> Reading symbols from /lib/libufs.so.6...Reading symbols from = /usr/lib/debug//lib/libufs.so.6.debug...done. >>> done. >>> Loaded symbols for /lib/libufs.so.6 >>> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >>> done. >>> Loaded symbols for /lib/libc.so.7 >>> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. >>> done. >>> Loaded symbols for /libexec/ld-elf.so.1 >>> #0 0x0181b024 in __floatdidf () >>> (gdb) bt >>> #0 0x0181b024 in __floatdidf () >>> #1 0x0180a8e0 in main (argc=3D, argv=3D) at /usr/src/sbin/fsck_ffs/main.c:519 >>> #2 0x01801664 in _start () >>> #3 0x418303a0 in .text () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >>=20 >> main.c's line 519 is part of: >>=20 >>> printf("(%ju frags, %ju blocks, %.1f%% fragmentation)\n", >>> (uintmax_t)n_ffree, (uintmax_t)n_bfree, >>> n_ffree * 100.0 / sblock.fs_dsize); >>=20 >>=20 >>=20 >> As for "df -m" --it failed in __floatdidf as well: >>=20 >>> # gdb df /var/crash/df.1056.core = = GNU gdb 6.1.1 = [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and = you are >>> welcome to change it and/or distribute copies of it under certain = conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for = details. >>> This GDB was configured as "powerpc-marcel-freebsd"... >>> Core was generated by `df -m'. >>> Program terminated with signal 11, Segmentation fault. >>> Reading symbols from /lib/libxo.so.0...Reading symbols from = /usr/lib/debug//lib/libxo.so.0.debug...done. >>> done. >>> Loaded symbols for /lib/libxo.so.0 >>> Reading symbols from /lib/libutil.so.9...Reading symbols from = /usr/lib/debug//lib/libutil.so.9.debug...done. >>> done. >>> Loaded symbols for /lib/libutil.so.9 >>> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >>> done. >>> Loaded symbols for /lib/libc.so.7 >>> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. >>> done. >>> Loaded symbols for /libexec/ld-elf.so.1 >>> #0 0x01802a18 in __floatdidf () >>> (gdb) bt >>> #0 0x01802a18 in __floatdidf () >>> #1 0x01802538 in prtstat (sfsp=3D0x41e24000, mwp=3D0xffffd930) at = /usr/src/bin/df/df.c:503 >>> #2 0x01801df0 in main (argc=3D, argv=3D) at /usr/src/bin/df/df.c:308 >>> #3 0x01800cdc in _start () >>> #4 0x418153a0 in .text () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >>=20 >> df.c's line 503 was part of: >>=20 >>> xo_emit(" {:used-percent/%5.0f}{U:%%}", >>> availblks =3D=3D 0 ? 100.0 : (double)used / = (double)availblks * 100.0); >>=20 >>=20 >>=20 >> Context details: >>=20 >>> # head = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap_worl= d-amd64-host-2016-11-26:11:38:36=20 >>> Script started on Sat Nov 26 11:38:36 2016 >>> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-ho= st WITH_META_MODE=3Dyes = MAKEOBJDIRPREFIX=3D/usr/obj/powerpcvtsc_clang_world make -j 5 buildworld >>> --- buildworld --- >>=20 >> . . . >>=20 >>=20 >>> # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host >>> TO_TYPE=3Dpowerpc >>> # >>> KERNCONF=3DGENERICvtsc-NODBG >>> TARGET=3D${TO_TYPE} >>> .if ${.MAKE.LEVEL} =3D=3D 0 >>> TARGET_ARCH=3D${TO_TYPE} >>> .export TARGET_ARCH >>> .endif >>> # >>> WITH_CROSS_COMPILER=3D >>> WITHOUT_SYSTEM_COMPILER=3D >>> # >>> WITH_LIBCPLUSPLUS=3D >>> WITH_BINUTILS_BOOTSTRAP=3D >>> WITH_CLANG_BOOTSTRAP=3D >>> WITH_CLANG=3D >>> WITH_CLANG_IS_CC=3D >>> WITH_CLANG_FULL=3D >>> WITH_CLANG_EXTRAS=3D >>> # lldb requires missing atomic 8-byte operations for powerpc = (non-64) >>> WITHOUT_LLDB=3D >>> # >>> WITH_BOOT=3D >>> WITHOUT_LIB32=3D >>> # >>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >>> WITHOUT_GCC_BOOTSTRAP=3D >>> WITHOUT_GCC=3D >>> WITHOUT_GCC_IS_CC=3D >>> WITHOUT_GNUCXX=3D >>> # >>> NO_WERROR=3D >>> #WERROR=3D >>> MALLOC_PRODUCTION=3D >>> # >>> WITH_DEBUG_FILES=3D >>=20 >>=20 >>> # more ~/src.configs/make.conf=20 >>> CFLAGS.gcc+=3D -v >=20 > Looking around in gdb there seem to be two __floatdidf routines with = differing code. >=20 > First showing the one that was used and failed: >=20 > (gdb) x/50i 0x0181afc0 > . . . > 0x181afcc <__floatdidf>: mflr r0 > 0x181afd0 <__floatdidf+4>: stw r0,4(r1) > 0x181afd4 <__floatdidf+8>: stwu r1,-32(r1) > 0x181afd8 <__floatdidf+12>: stw r31,28(r1) > 0x181afdc <__floatdidf+16>: stw r30,24(r1) > 0x181afe0 <__floatdidf+20>: bl 0x182e96c <.got+20> > 0x181afe4 <__floatdidf+24>: mr r31,r1 > 0x181afe8 <__floatdidf+28>: xoris r3,r3,32768 > 0x181afec <__floatdidf+32>: lis r5,17200 > 0x181aff0 <__floatdidf+36>: mflr r30 > 0x181aff4 <__floatdidf+40>: stw r3,12(r31) > 0x181aff8 <__floatdidf+44>: stw r5,8(r31) > 0x181affc <__floatdidf+48>: lwz r3,-16(r30) > 0x181b000 <__floatdidf+52>: lwz r6,-20(r30) > 0x181b004 <__floatdidf+56>: lfd f1,8(r31) > 0x181b008 <__floatdidf+60>: stw r4,20(r31) > 0x181b00c <__floatdidf+64>: stw r5,16(r31) > 0x181b010 <__floatdidf+68>: lfd f13,16(r31) > 0x181b014 <__floatdidf+72>: lwz r0,36(r1) > 0x181b018 <__floatdidf+76>: lwz r31,28(r1) > 0x181b01c <__floatdidf+80>: lwz r30,24(r1) > 0x181b020 <__floatdidf+84>: lfs f2,0(r3) > 0x181b024 <__floatdidf+88>: lwz r3,-12(r30) > 0x181b028 <__floatdidf+92>: lfs f0,0(r6) > 0x181b02c <__floatdidf+96>: lfs f12,0(r3) > 0x181b030 <__floatdidf+100>: fsub f0,f1,f0 > 0x181b034 <__floatdidf+104>: fmul f0,f0,f2 > 0x181b038 <__floatdidf+108>: fadd f0,f0,f12 > 0x181b03c <__floatdidf+112>: fadd f1,f13,f0 > 0x181b040 <__floatdidf+116>: addi r1,r1,32 > 0x181b044 <__floatdidf+120>: mtlr r0 > 0x181b048 <__floatdidf+124>: blr > . . . >=20 > Then showing the one that was not used that I found: >=20 > (gdb) disass __floatdidf > Dump of assembler code for function __floatdidf: > 0x4199fc8c <__floatdidf+0>: mflr r0 > 0x4199fc90 <__floatdidf+4>: stw r0,4(r1) > 0x4199fc94 <__floatdidf+8>: stwu r1,-32(r1) > 0x4199fc98 <__floatdidf+12>: stw r31,28(r1) > 0x4199fc9c <__floatdidf+16>: stw r30,24(r1) > 0x4199fca0 <__floatdidf+20>: mr r31,r1 > 0x4199fca4 <__floatdidf+24>: srawi r5,r3,31 > 0x4199fca8 <__floatdidf+28>: bl 0x41a0a288 <.got+14428> > 0x4199fcac <__floatdidf+32>: cmpwi r3,0 > 0x4199fcb0 <__floatdidf+36>: addc r6,r4,r5 > 0x4199fcb4 <__floatdidf+40>: adde r6,r3,r5 > 0x4199fcb8 <__floatdidf+44>: lis r3,17200 > 0x4199fcbc <__floatdidf+48>: xor r5,r6,r5 > 0x4199fcc0 <__floatdidf+52>: mflr r30 > 0x4199fcc4 <__floatdidf+56>: bge- 0x4199fccc <__floatdidf+64> > 0x4199fcc8 <__floatdidf+60>: neg r4,r4 > 0x4199fccc <__floatdidf+64>: lwz r12,-3124(r30) > 0x4199fcd0 <__floatdidf+68>: stw r5,20(r31) > 0x4199fcd4 <__floatdidf+72>: stw r4,12(r31) > 0x4199fcd8 <__floatdidf+76>: lwz r4,-3120(r30) > 0x4199fcdc <__floatdidf+80>: stw r3,16(r31) > 0x4199fce0 <__floatdidf+84>: stw r3,8(r31) > 0x4199fce4 <__floatdidf+88>: lfd f1,16(r31) > 0x4199fce8 <__floatdidf+92>: lfd f3,8(r31) > 0x4199fcec <__floatdidf+96>: lfs f0,0(r12) > 0x4199fcf0 <__floatdidf+100>: lfs f2,0(r4) > 0x4199fcf4 <__floatdidf+104>: fsub f1,f1,f0 > 0x4199fcf8 <__floatdidf+108>: fsub f0,f3,f0 > 0x4199fcfc <__floatdidf+112>: fmul f1,f1,f2 > 0x4199fd00 <__floatdidf+116>: fadd f1,f0,f1 > 0x4199fd04 <__floatdidf+120>: bge- 0x4199fd0c <__floatdidf+128> > 0x4199fd08 <__floatdidf+124>: fneg f1,f1 > 0x4199fd0c <__floatdidf+128>: lwz r0,36(r1) > 0x4199fd10 <__floatdidf+132>: lwz r31,28(r1) > 0x4199fd14 <__floatdidf+136>: lwz r30,24(r1) > 0x4199fd18 <__floatdidf+140>: addi r1,r1,32 > 0x4199fd1c <__floatdidf+144>: mtlr r0 > 0x4199fd20 <__floatdidf+148>: blr > End of assembler dump. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Mon Nov 28 00:34:09 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A062C59A83 for ; Mon, 28 Nov 2016 00:34:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-33.reflexion.net [208.70.210.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB05822AC for ; Mon, 28 Nov 2016 00:34:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7231 invoked from network); 28 Nov 2016 00:33:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 28 Nov 2016 00:33:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 27 Nov 2016 19:33:52 -0500 (EST) Received: (qmail 14785 invoked from network); 28 Nov 2016 00:33:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Nov 2016 00:33:51 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0C625EC8FEB; Sun, 27 Nov 2016 16:34:06 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: WITH_CLANG_BOOTSTRAP= for TARGET_ARCH=powerpc64 but bound to devel/powerpc64-binutils : can such be done? Message-Id: <6CB31FDE-DA0E-46AD-BFB1-69B9A9DBC4E1@dsl-only.net> Date: Sun, 27 Nov 2016 16:34:05 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML To: Bryan Drewery X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 00:34:09 -0000 Currently head has switched to clang 3.9.0 but my TARGET_ARCH=powerpc64for clang experiments for buildworld are blocked by WITH_BINUTILS_BOOTSTRAP= 's ld stopping the buildworld via failing asserts. What I'd like to do is build the bootstrap clang but bound to a devel/powerpc64-binutils vintage to see if that works. So binutils being "cross tool chain" (even when directly invoked by clang) but clang itself not being cross tool chain but bootstrapped? (elftoolchain may need to be considered with binutils.) Do you know if there is a way for me to make assignments in a SRC_ENV_CONF file that might enable such a combination? Or do I need to modify the build environment to be non-standard? So far in my reading /usr/src/Makefile.inc1 I've not seen any combination of settings that look like it would go through and work for what I've described here. === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Nov 28 03:01:35 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8737C585DE for ; Mon, 28 Nov 2016 03:01:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-36.reflexion.net [208.70.210.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D4DE3C9 for ; Mon, 28 Nov 2016 03:01:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12920 invoked from network); 28 Nov 2016 03:01:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Nov 2016 03:01:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 27 Nov 2016 22:01:40 -0500 (EST) Received: (qmail 13450 invoked from network); 28 Nov 2016 03:01:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Nov 2016 03:01:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 09FBDEC9011; Sun, 27 Nov 2016 19:01:33 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: head -r309179 clang 3.9.0 for TARGET_ARCH=powerpc64 with devel/powerpc64-binutils used: WITH_LIB32= related assembler source rejected. . . Message-Id: Date: Sun, 27 Nov 2016 19:01:32 -0800 Cc: Justin Hibbits , Nathan Whitehorn To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 03:01:35 -0000 [Note: ld from WITH_BINTOOLS_BOOTSTRAP=3D for buildworld fails and stops buildworld. This explains the use of devel/powerpc64-binutils below.] Using clang 3.9.0 for TARGET_ARCH=3Dpowerpc64 with devel/powerpc64-binutils (of an appropriate vintage) apparently requires r1 instead of 1 for a register name --and so on. It turns out that trying to use WITH_LIB32=3D for TARGET_ARCH=3Dpowerpc64 with devel/powerpc64-binutils runs into assembler source files that are rejected for this reason. There are also complaints about invalid mnemonics (mflr and mr). The error reports: (Other files may well have the same sorts of problems.) > --- lib/csu__L --- > Building = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/w= orld32/usr/src/lib/csu/powerpc/crti.o > . . . > --- crti.o --- > /usr/src/lib/csu/powerpc/crti.S:34:13: error: unexpected token in = memory operand > stwu 1,-16(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:35:2: error: invalid instruction = mnemonic 'mflr' > mflr 0 > ^ > /usr/src/lib/csu/powerpc/crti.S:36:12: error: unexpected token in = memory operand > stw 31,12(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:37:11: error: unexpected token in = memory operand > stw 0,20(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:38:2: error: invalid instruction = mnemonic 'mr' > mr 31,1 > ^ > /usr/src/lib/csu/powerpc/crti.S:45:13: error: unexpected token in = memory operand > stwu 1,-16(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:46:2: error: invalid instruction = mnemonic 'mflr' > mflr 0 > ^ > /usr/src/lib/csu/powerpc/crti.S:47:12: error: unexpected token in = memory operand > stw 31,12(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:48:11: error: unexpected token in = memory operand > stw 0,20(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:49:2: error: invalid instruction = mnemonic 'mr' > mr 31,1 > ^ > *** [crti.o] Error code 1 >=20 > make[5]: stopped in /usr/src/lib/csu/powerpc > .ERROR_TARGET=3D'crti.o' > = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc= .powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o.meta' > .MAKE.LEVEL=3D'5' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > .CURDIR=3D'/usr/src/lib/csu/powerpc' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc6= 4/usr/src/world32/usr/src/lib/csu/powerpc' > .TARGETS=3D'all' > = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc6= 4/usr/src/lib32' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'powerpc' > MACHINE_ARCH=3D'powerpc' > = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc= .powerpc64/usr/src/world32' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20160818' > = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/u= sr/src/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/= powerpc.powerpc64/usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_= altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/bin:/usr/obj/powerp= c64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/sbin:/us= r/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/= usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64= /usr/src/world32/usr/src' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/csu/powerpc/Makefile = /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk = /usr/src/lib/csu/powerpc/../Makefile.inc = /usr/src/lib/csu/powerpc/../../Makefile.inc /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' > .PATH=3D'. /usr/src/lib/csu/powerpc = /usr/src/lib/csu/powerpc/../common' > --- lib/libc_nonshared__L --- > Building = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/w= orld32/usr/src/lib/libc_nonshared/iconv.o > --- lib/csu__L --- > 1 error The .meta report: > # more = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/w= orld32/usr/src/lib/csu/powerpc/crti.o.meta > # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/w= orld32/usr/src/lib/csu/powerpc/crti.o.meta > CMD /usr/bin/clang -m32 -DCOMPAT_32BIT -mcpu=3Dpowerpc = -L/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /lib32/usr/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc= 64/usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /lib32/usr/lib32 -O2 -pipe -I/usr/src/lib/csu/powerpc/../common = -I/usr/src/lib/csu/powerpc/../../libc/include -std=3Dgnu99 = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter = -Wcast-align -Wchar-subscripts -Winline -Wnested-externs = -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wthread-safety -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Qunused-arguments -c = /usr/src/lib/csu/powerpc/crti.S -o crti.o > CMD=20 > CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/w= orld32/usr/src/lib/csu/powerpc > TARGET crti.o > -- command output -- > /usr/src/lib/csu/powerpc/crti.S:34:13: error: unexpected token in = memory operand > stwu 1,-16(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:35:2: error: invalid instruction = mnemonic 'mflr' > mflr 0 > ^ > /usr/src/lib/csu/powerpc/crti.S:36:12: error: unexpected token in = memory operand > stw 31,12(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:37:11: error: unexpected token in = memory operand > stw 0,20(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:38:2: error: invalid instruction = mnemonic 'mr' > mr 31,1 > ^ > /usr/src/lib/csu/powerpc/crti.S:45:13: error: unexpected token in = memory operand > stwu 1,-16(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:46:2: error: invalid instruction = mnemonic 'mflr' > mflr 0 > ^ > /usr/src/lib/csu/powerpc/crti.S:47:12: error: unexpected token in = memory operand > stw 31,12(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:48:11: error: unexpected token in = memory operand > stw 0,20(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:49:2: error: invalid instruction = mnemonic 'mr' > mr 31,1 > ^ > *** Error code 1 >=20 > -- filemon acquired metadata -- . . . Supporting details: > # more = ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host=20= > TO_TYPE=3Dpowerpc64 > TOOLS_TO_TYPE=3D${TO_TYPE} > VERSION_CONTEXT=3D12.0 > # > KERNCONF=3DGENERIC64vtsc-NODBG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITH_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > # > # For TO (so-called "cross") stages . . . > # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . = . > # > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # > # =46rom based on clang (via system). . . > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif head -r309179 needed a workaround to build: > # svnlite diff /usr/src/sys/netipsec/keydb.h > Index: /usr/src/sys/netipsec/keydb.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/netipsec/keydb.h (revision 309179) > +++ /usr/src/sys/netipsec/keydb.h (working copy) > @@ -35,6 +35,7 @@ > =20 > #ifdef _KERNEL > =20 > +#include > #include > =20 > #include Such a change was later checked in as -r309201 . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Nov 28 03:10:38 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5109AC58998 for ; Mon, 28 Nov 2016 03:10:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 04B229D5 for ; Mon, 28 Nov 2016 03:10:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11891 invoked from network); 28 Nov 2016 03:10:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Nov 2016 03:10:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 27 Nov 2016 22:10:43 -0500 (EST) Received: (qmail 5869 invoked from network); 28 Nov 2016 03:10:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Nov 2016 03:10:43 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C8D5DEC9011; Sun, 27 Nov 2016 19:10:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_CLANG_BOOTSTRAP= for TARGET_ARCH=powerpc64 but bound to devel/powerpc64-binutils : can such be done? From: Mark Millard In-Reply-To: <6CB31FDE-DA0E-46AD-BFB1-69B9A9DBC4E1@dsl-only.net> Date: Sun, 27 Nov 2016 19:10:35 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <864D23CD-58C5-4E38-89E7-DAE0A3DEA71A@dsl-only.net> References: <6CB31FDE-DA0E-46AD-BFB1-69B9A9DBC4E1@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 03:10:38 -0000 [Looks like I misread something so. . .] On 2016-Nov-27, at 4:34 PM, Mark Millard wrote: > Currently head has switched to clang 3.9.0 but my > TARGET_ARCH=3Dpowerpc64for clang experiments for buildworld are = blocked > by WITH_BINUTILS_BOOTSTRAP=3D 's ld stopping the buildworld via = failing > asserts. >=20 > What I'd like to do is build the bootstrap clang but bound to a > devel/powerpc64-binutils vintage to see if that works. So binutils > being "cross tool chain" (even when directly invoked by clang) but > clang itself not being cross tool chain but bootstrapped? >=20 > (elftoolchain may need to be considered with binutils.) >=20 > Do you know if there is a way for me to make assignments in a > SRC_ENV_CONF file that might enable such a combination? Or > do I need to modify the build environment to be non-standard? >=20 > So far in my reading /usr/src/Makefile.inc1 I've not seen any > combination of settings that look like it would go through and > work for what I've described here. I misread something and the following seems to have worked: (I tend to be explicit about some things that I do not need to be in such files: it helps em remember and understand some issues.) # more = ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host=20= TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D # world32/usr/src/lib/csu/powerpc/crti.o got: # csu/powerpc/crti.S:34:13: error: unexpected token in memory operand # csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 'mflr' # and the like. So avoid LIB32. WITHOUT_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif I have not tested what the buildworld produced yet. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Nov 28 08:43:03 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0656C57D5C for ; Mon, 28 Nov 2016 08:43:03 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) Received: from mailer238.gate85.rs.smtp.com (mailer238.gate85.rs.smtp.com [74.91.85.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 810BA1A25 for ; Mon, 28 Nov 2016 08:43:03 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) X-MSFBL: zKegfabCdy5G+6/dx8hLwke7V/nqotpxz18j0XTSwtk=|eyJnIjoiU25zdGVsZWN vbV9kZWRpY2F0ZWRfcG9vbCIsImIiOiI3NF85MV84NV8yMzgiLCJyIjoiZnJlZWJ zZC1wcGNAZnJlZWJzZC5vcmcifQ== Received: from [192.168.80.31] ([192.168.80.31:42368] helo=rs-ord-mta03-1.smtp.com) by rs-ord-mta03-4.smtp.com (envelope-from ) (ecelerity 4.2.1.55028 r(Core:4.2.1.12)) with ESMTP id 9B/27-14625-C59EB385; Mon, 28 Nov 2016 08:22:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1480321372; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=GKymE5ZYHsXsPrKZl3q05wCJ4CWwfhfIF8kOeByRmt0=; b=WsplFAVzrhVofhzTR2s2nOksYKix/1FwAEpfCSYL76dvZPTwRAY3wltvLr4d/sAp hy+uTMFYOWyiMJsZSxy5wiGB+LVSciUcHQ2GwBWeaF/Fnt3uRh+VKEWIyqp/L4LD UheGiW4/zY2XDGdEIg2aoKmwwazLwClkj4Im4xXOTiY=; Received: from [70.79.69.78] ([70.79.69.78:33590] helo=S01061c1b689e28c7.vc.shawcable.net) by rs-ord-mta03-1.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id 8C/11-02371-B59EB385; Mon, 28 Nov 2016 08:22:52 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snsresearchreports.com To: freebsd-ppc@freebsd.org Subject: The VoLTE (Voice over LTE) Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Mon, 28 Nov 2016 00:22:44 -0800 Message-ID: <89084065034321365213104@Ankur> X-Report-Abuse: SMTP.com is an email service provider. Our abuse team cares about your feedback. Please contact abuse@smtp.com for further investigation. X-SMTPCOM-Tracking-Number: f4075998-6f9c-4514-8ee0-6521dfbc9456 X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 08:43:03 -0000 The VoLTE (Voice over LTE) Ecosystem: 2016 =96 2030 =96 Opportunities, Chal= lenges, Strategies & Forecasts (Report) Hello Let me offer you the latest SNS Research report to you and your team, "The = VoLTE (Voice over LTE) Ecosystem: 2016 =96 2030 =96 Opportunities, Challeng= es, Strategies & Forecasts" Below is the report highlight and if you like I= can send you sample pages for your details inside.=20 =20 SNS Research estimates that VoLTE service revenue will grow at a CAGR of 34= % between 2016 and 2020. By the end of 2020, VoLTE subscribers will account= for more than $200 Billion in revenue. Although traditional voice services= will constitute a major proportion of this figure, nearly 15% of the reven= ue will be driven by video calling and supplementary services. Report Information: Release Date: Oct 2016 Number of Pages: 217 Number of Tables and Figures: 47 Key Questions Answered: How big is the VoLTE opportunity=3F What trends, challenges and barriers are influencing its growth=3F How is the ecosystem evolving by segment and region=3F What will the market size be in 2020 and at what rate will it grow=3F Which regions and countries will see the highest percentage of growth=3F How will VoLTE capable smartphone shipments grow over time=3F Who are the key market players and what are their strategies=3F How can VoLTE help operators in reducing the flow of voice subscribers to O= TT application providers=3F What are the prospects of Wi-Fi calling, RCS and WebRTC=3F What much will operators invest in VoLTE service assurance solutions=3F How can mobile operators and MVNOs capitalize on VoLTE to drive revenue gro= wth=3F How can VoLTE help operators in refarming their 2G and 3G spectrum assets=3F What is the status of international roaming and VoLTE-to-VoLTE interconnect= ion agreements=3F What strategies should VoLTE solution providers and mobile operators adopt = to remain competitive=3F =20 Key Findings: The report has the following key findings: By 2020, SNS Research estimates that VoLTE services will account for over $= 200 Billion in annual service revenue, as mobile operators remain committed= to VoLTE as the long term solution to secure a fully native IP-based telep= hony experience. As the transition to VoLTE accelerates, mobile operators have already begun= shutting down their legacy networks in a bid to reallocate additional spec= trum to their LTE networks. Japan and South Korea have already shut down their 2G networks, and multipl= e operators in other parts of the world, including the United States, are i= n the processing of switching off 2G services. Some operators, such as Telenor Norway, are seeking the closure o= f their 3G networks as early as 2020. Nearly all VoLTE operators are integrating their VoLTE services with Wi-Fi = calling in a bid to offer voice services in areas where their licensed spec= trum coverage is limited. The vendor ecosystem is continuing to consolidate with several acquisitions= such as Sonus Networks=92 recent takeover of IP communications specialist = Taqua. The report covers the following topics: VoLTE ecosystem Market drivers and barriers VoLTE infrastructure, devices, roaming and interconnection technology Case studies of 20 commercial VoLTE deployments OTT mobile voice and video services Complimentary technologies including Wi-Fi calling, RCS and WebRTC MCPTT (Mission Critical Push-to-Talk) voice services VoLTE services over MVNO networks Service assurance platforms for VoLTE Regulatory landscape, collaborative initiatives and standardization Industry roadmap and value chain Profiles and strategies of 100 leading ecosystem players including device O= EMs, VoLTE solution providers and mobile operators Strategic recommendations for VoLTE solution providers and mobile operators Market analysis and forecasts from 2016 till 2030 Forecast Segmentation: VoLTE subscription, service revenue and infrastructure revenue forecasts ar= e provided for each of the following submarkets and their subcategories: VoLTE Services Voice Telephony Video and Supplementary Services VoLTE Infrastructure CSCF (Call Session Control Function) Servers SBCs (Session Border Controllers) VoLTE Application Servers Other IMS Elements (HSS, BGCF, MGCF & MRF) VoLTE Capable PCRF (Policy & Charging Rules Function) Solutions Regional Submarkets Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe Report Pricing: =20 Single User License: USD 2,500 Company Wide License: USD 3,500 =20 Ordering Process: =20 Please provide the following information: Report Title - Report License - (Single User/Company Wide) Name - Email - Job Title - Company - Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents and List of figures mentioned in report are given below for= more inside. I look forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snsresearchreports.com =20 _________________________________________________________________________ Table of Contents(page number): =20 1: Introduction 1.1 Executive Summary 1.2 Topics Covered 1.3 Forecast Segmentation 1.4 Key Questions Answered 1.5 Key Findings 1.6 Methodology 1.7 Target Audience 1.8 Companies & Organizations Mentioned =20 2: An Overview of VoLTE 2.1 What is VoLTE=3F 2.2 Architectural Evolution of VoLTE 2.2.1 CSFB (Circuit-Switched Fallback): The First Step Towards VoLTE 2.2.2 The Push From CDMA Operators 2.2.3 Towards an IMS Based VoLTE Solution 2.2.4 SRVCC (Single Radio Voice Call Continuity) 2.2.5 Integrating Video Telephony 2.3 Key Enabling Technologies 2.3.1 VoLTE Infrastructure 2.3.1.1 IMS Core: CSCF, HSS, BGCF & MGCF 2.3.1.2 VoLTE Application Servers 2.3.1.3 SBC (Session Border Controller) 2.3.1.4 MRF (Media Resource Function) 2.3.1.5 PCRF (Policy and Charging Rules Function) 2.3.2 VoLTE Devices 2.3.3 Roaming & Interconnection Technology 2.3.3.1 LBO (Local Breakout) 2.3.3.2 S8HR (S8 Home Routing) 2.4 Market Growth Drivers 2.4.1 Spectral Efficiency & Cost Reduction 2.4.2 Enabling HD Voice, Video Calling & Rich IP Communications 2.4.3 Improved Battery Life 2.4.4 Integration with Wi-Fi: Enhanced Indoor Voice Coverage 2.4.5 Bundling Voice with Other Services 2.4.6 Fighting the OTT Threat 2.5 Market Barriers 2.5.1 Initial Lack of Compatible Devices 2.5.2 Roaming & Interconnect Issues 2.5.3 Limited Revenue Potential 2.5.4 Service Assurance Challenges =20 3: Collaboration, Standardization & Regulatory Landscape 3.1 3GPP (3rd Generation Partnership Project) 3.1.1 Release 8 3.1.2 Release 9 3.1.3 Release 10 3.1.4 Release 11 3.1.5 Release 12, 13 & Beyond 3.2 GSMA 3.2.1 Feature Requirements 3.2.1.1 IR.92: IMS Profile for Voice and SMS 3.2.1.2 IR.94: IMS Profile for Conversational Video Service 3.2.2 Roaming, Interworking & Other Guidelines 3.2.2.1 IR.64: IMS Service Centralization & Continuity Guidelines 3.2.2.2 IR.65: IMS Roaming & Interworking Guidelines 3.2.2.3 IR.88: LTE Roaming Guidelines 3.3 VoLTE Interworking Technology Consultation Group, Korea =20 4: VoLTE Deployment Case Studies 4.1 AT&T 4.1.1 Service Launch Strategy 4.1.2 Vendor Selection 4.1.3 Future Prospects 4.2 China Mobile 4.2.1 Service Launch Strategy 4.2.2 Vendor Selection 4.2.3 Future Prospects 4.3 DT (Deutsche Telekom) 4.3.1 Service Launch Strategy 4.3.2 Vendor Selection 4.3.3 Future Prospects 4.4 Du (Emirates Integrated Telecommunications Company) 4.4.1 Service Launch Strategy 4.4.2 Vendor Selection 4.4.3 Future Prospects 4.5 EE 4.5.1 Service Launch Strategy 4.5.2 Vendor Selection 4.5.3 Future Prospects 4.6 KDDI Corporation 4.6.1 Service Launch Strategy 4.6.2 Vendor Selection 4.6.3 Future Prospects 4.7 KT Corporation 4.7.1 Service Launch Strategy 4.7.2 Vendor Selection 4.7.3 Future Prospects 4.8 LG Uplus 4.8.1 Service Launch Strategy 4.8.2 Vendor Selection 4.8.3 Future Prospects 4.9 NTT DoCoMo 4.9.1 Service Launch Strategy 4.9.2 Vendor Selection 4.9.3 Future Prospects 4.10 Orange 4.10.1 Service Launch Strategy 4.10.2 Vendor Selection 4.10.3 Future Prospects 4.11 Reliance Jio Infocomm 4.11.1 Service Launch Strategy 4.11.2 Vendor Selection 4.11.3 Future Prospects 4.12 Rogers Communications 4.12.1 Service Launch Strategy 4.12.2 Vendor Selection 4.12.3 Future Prospects 4.13 Singtel Group 4.13.1 Service Launch Strategy 4.13.2 Vendor Selection 4.13.3 Future Prospects 4.14 SK Telecom 4.14.1 Service Launch Strategy 4.14.2 Vendor Selection 4.14.3 Future Prospects 4.15 SoftBank Group 4.15.1 Service Launch Strategy 4.15.2 Vendor Selection 4.15.3 Future Prospects 4.16 Swisscom 4.16.1 Service Launch Strategy 4.16.2 Vendor Selection 4.16.3 Future Prospects 4.17 Telef=F3nica Group 4.17.1 Service Launch Strategy 4.17.2 Vendor Selection 4.17.3 Future Prospects 4.18 Telstra 4.18.1 Service Launch Strategy 4.18.2 Vendor Selection 4.18.3 Future Prospects 4.19 Verizon Communications 4.19.1 Service Launch Strategy 4.19.2 Vendor Selection 4.19.3 Future Prospects 4.20 Vodafone Group 4.20.1 Service Launch Strategy 4.20.2 Vendor Selection 4.20.3 Future Prospects =20 5: VoLTE Industry Roadmap & Value Chain 5.1 Industry Roadmap 5.1.1 2016 =96 2020: Large Scale VoLTE Rollouts 5.1.2 2020 =96 2025: Building New Services on VoLTE Architecture 5.1.3 2025 =96 2030: Continued Investments with 5G Rollouts 5.2 Value Chain 5.2.1 Enabling Technology Providers 5.2.2 VoLTE & IMS Infrastructure Suppliers 5.2.3 VoLTE Device OEMs 5.2.4 Roaming, Billing & Supplementary Service Providers 5.2.5 Mobile Operators 5.2.6 Test, Measurement & Performance Specialists =20 6: Key Market Players 6.1 Accedian Networks 6.2 Affirmed Networks 6.3 ALEPO 6.4 Altair Semiconductor 6.5 Amdocs 6.6 Anritsu Corporation 6.7 Anritsu Corporation 6.8 Apple 6.9 Aptilo Networks 6.10 Aricent 6.11 Astellia 6.12 Asus (ASUSTeK Computer) 6.13 BICS 6.14 Broadcom 6.15 BroadSoft 6.16 BT Group 6.17 CCN (Cirrus Core Networks) 6.18 CellMining 6.19 Cellwize 6.20 CENX 6.21 CEVA 6.22 Cirpack 6.23 Cisco Systems 6.24 D2 Technologies 6.25 Dialogic Corporation 6.26 DigitalRoute 6.27 Ecrio 6.28 Empirix 6.29 Ericsson 6.30 EXFO 6.31 F5 Networks 6.32 Fujitsu 6.33 GCT Semiconductor 6.34 GENBAND 6.35 Gigamon 6.36 GL Communications 6.37 Hitachi 6.38 HPE (Hewlett Packard Enterprise) 6.39 HTC Corporation 6.40 Huawei 6.41 iBasis 6.42 IBM 6.43 Imagination Technologies 6.44 IMSWorkX 6.45 InfoVista 6.46 Intel Corporation 6.47 InterDigital 6.48 Interop Technologies 6.49 Iskratel 6.50 Italtel 6.51 Ixia 6.52 Keysight Technologies 6.53 Lenovo 6.54 LG Electronics 6.55 Metaswitch Networks 6.56 Mitel Networks Corporation 6.57 Mobileum 6.58 Monolith Software 6.59 Mushroom Networks 6.60 MYCOM OSI 6.61 Napatech 6.62 NEC Corporation 6.63 NetScout Systems 6.64 NewNet Communication Technologies 6.65 Nexus Telecom 6.66 Nokia Networks 6.67 NXP Semiconductors 6.68 OpenCloud 6.69 Openet 6.70 Optulink 6.71 Oracle Communications 6.72 Pantech 6.73 Polystar 6.74 Qualcomm 6.75 Quortus 6.76 RADCOM 6.77 Radisys Corporation 6.78 Redknee Solutions 6.79 Rohde & Schwarz 6.80 Samsung Electronics 6.81 Sandvine 6.82 Sansay 6.83 Sequans Communications 6.84 Sharp Corporation 6.85 SIGOS 6.86 Sonus Networks 6.87 Sony Mobile Communications 6.88 Spirent Communications 6.89 SPIRIT DSP 6.90 Spreadtrum Communications 6.91 Summit Tech 6.92 Syniverse 6.93 SysMech 6.94 TNS (Transaction Network Services) 6.95 Viavi Solutions 6.96 VMware 6.97 VoiceAge Corporation 6.98 Voipfuture 6.99 WIT Software 6.100 ZTE =20 7: Market Analysis & Forecasts 7.1 Global Outlook of VoLTE 7.2 VoLTE Subscriptions & Service Revenue 7.2.1 VoLTE Subscriptions 7.2.2 VoLTE Service Revenue 7.2.3 Segmentation by Application 7.2.4 Voice Telephony 7.2.5 Video & Supplementary Services 7.3 VoLTE Infrastructure 7.3.1 Segmentation by Submarket 7.3.2 CSCF Servers 7.3.3 SBCs 7.3.4 VoLTE Application Servers 7.3.5 Other IMS Elements (HSS, BGCF, MGCF & MRF) 7.3.6 VoLTE Capable PCRF Solutions 7.4 Segmentation by Region 7.4.1 Asia Pacific 7.4.2 Eastern Europe 7.4.3 Latin & Central America 7.4.4 Middle East & Africa 7.4.5 North America 7.4.6 Western Europe =20 8: Conclusion, Key Trends & Strategic Recommendations 8.1 Why is the Market Poised to Grow=3F 8.2 Competitive Industry Landscape: Acquisitions, Alliances & Consolidation 8.3 Geographic Outlook: Which Countries Offer the Highest Growth Potential=3F 8.4 Monetization: Can VoLTE Drive Revenue Growth=3F 8.5 Operator Branded OTT Services: Implications for VoLTE 8.6 Virtualization: Moving VoLTE to the Cloud 8.7 Growing Investments in VoLTE Service Assurance 8.8 Prospects of the EVS (Enhanced Voice Services) Codec 8.9 Convergence with Wi-Fi Calling 8.9.1 Moving Towards IMS-Based Wi-Fi Calling Services 8.9.2 Future Prospects 8.10 Opportunities for MVNOs 8.10.1 Enabling Service Differentiation 8.10.2 Growing MVNE (Mobile Virtual Network Enabler) Investments in VoLTE I= nfrastructure 8.10.3 How Big is the VoLTE Service Revenue Opportunity for MVNOS=3F 8.11 WebRTC: Friend or Foe=3F 8.12 Status of RCS Adoption 8.13 Prospects of Roaming and Interconnected VoLTE Services 8.14 MCPTT over VoLTE: Enabling Critical Communications 8.15 Strategic Recommendations 8.15.1 VoLTE Solution Providers 8.15.2 Mobile Operators & MVNOs =20 List of Figures: =20 Figure 1: The CSFB Mechanism for LTE Figure 2: VoLTE via IMS Figure 3: SRVCC Network Architecture Figure 4: Video Telephony with VoLTE Figure 5: Global VoLTE Capable Smartphone Shipments: 2016 - 2030 (Millions = of Units) Figure 6: VoLTE Industry Roadmap Figure 7: VoLTE Value Chain Figure 8: Global VoLTE Subscriptions: 2016 - 2030 (Millions) Figure 9: Global VoLTE Service Revenue: 2016 - 2030 ($ Billion) Figure 10: Global VoLTE Service Revenue by Application: 2016 - 2030 ($ Bill= ion) Figure 11: Global VoLTE Based Voice Telephony Service Revenue: 2016 - 2030 = ($ Billion) Figure 12: Global VoLTE Based Video & Supplementary Applications Service Re= venue: 2016 - 2030 ($ Billion) Figure 13: Global VoLTE Infrastructure Revenue: 2016 - 2030 ($ Million) Figure 14: Global VoLTE Infrastructure Revenue by Submarket: 2016 - 2030 ($= Million) Figure 15: Global CSCF Server Revenue: 2016 - 2030 ($ Million) Figure 16: Global SBC Revenue: 2016 - 2030 ($ Million) Figure 17: Global VoLTE Application Server Revenue: 2016 - 2030 ($ Million) Figure 18: Global Other IMS Elements (HSS, BGCF, MGCF & MRF) Revenue: 2016 = - 2030 ($ Million) Figure 19: Global VoLTE Capable PCRF Solution Revenue: 2016 - 2030 ($ Milli= on) Figure 20: VoLTE Subscriptions by Region: 2016 - 2030 (Millions) Figure 21: VoLTE Service Revenue by Region: 2016 - 2030 ($ Billion) Figure 22: VoLTE Infrastructure Revenue by Region: 2016 - 2030 ($ Million) Figure 23: Asia Pacific VoLTE Subscriptions: 2016 - 2030 (Millions) Figure 24: Asia Pacific VoLTE Service Revenue: 2016 - 2030 ($ Billion) Figure 25: Asia Pacific VoLTE Infrastructure Revenue: 2016 - 2030 ($ Millio= n) Figure 26: Eastern Europe VoLTE Subscriptions: 2016 - 2030 (Millions) Figure 27: Eastern Europe VoLTE Service Revenue: 2016 - 2030 ($ Billion) Figure 28: Eastern Europe VoLTE Infrastructure Revenue: 2016 - 2030 ($ Mill= ion) Figure 29: Latin & Central America VoLTE Subscriptions: 2016 - 2030 (Millio= ns) Figure 30: Latin & Central America VoLTE Service Revenue: 2016 - 2030 ($ Bi= llion) Figure 31: Latin & Central America VoLTE Infrastructure Revenue: 2016 - 203= 0 ($ Million) Figure 32: Middle East & Africa VoLTE Subscriptions: 2016 - 2030 (Millions) Figure 33: Middle East & Africa VoLTE Service Revenue: 2016 - 2030 ($ Billi= on) Figure 34: Middle East & Africa VoLTE Infrastructure Revenue: 2016 - 2030 (= $ Million) Figure 35: North America VoLTE Subscriptions: 2016 - 2030 (Millions) Figure 36: North America VoLTE Service Revenue: 2016 - 2030 ($ Billion) Figure 37: North America VoLTE Infrastructure Revenue: 2016 - 2030 ($ Milli= on) Figure 38: Western Europe VoLTE Subscriptions: 2016 - 2030 (Millions) Figure 39: Western Europe VoLTE Service Revenue: 2016 - 2030 ($ Billion) Figure 40: Western Europe VoLTE Infrastructure Revenue: 2016 - 2030 ($ Mill= ion) Figure 41: Global Spending on VoLTE Service Assurance Solutions: 2016 - 203= 0 ($ Million) Figure 42: Audio Bandwidth Comparison between EVS and Legacy Codecs Figure 43: Wi-Fi Calling Scenarios Figure 44: IMS-based Wi-Fi Calling Service Architecture Figure 45: Managed IMS Core/IP Services for MVNOs Figure 46: Global VoLTE Service Revenue over MVNO Networks: 2016 - 2030 ($ = Billion) Figure 47: RCS Business Model =20 Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snsresearchreports.com =20 =20 To unsubscribe please click on the link below or send an email with unsubsc= ribe in the subject line to: remove@snsreports.com =20 From owner-freebsd-ppc@freebsd.org Mon Nov 28 11:02:22 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2201C594EA for ; Mon, 28 Nov 2016 11:02:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7717B134D for ; Mon, 28 Nov 2016 11:02:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15301 invoked from network); 28 Nov 2016 11:02:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Nov 2016 11:02:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Mon, 28 Nov 2016 06:02:31 -0500 (EST) Received: (qmail 15091 invoked from network); 28 Nov 2016 11:02:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Nov 2016 11:02:30 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8C376EC7B39; Mon, 28 Nov 2016 03:02:19 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Cross built head -r309179 TARGET_ARCH=powerpc64 with clang 3.9.0/powerpc64-binutils based buildworld operates; but fails "self-hosted buildworld" for undefined references Message-Id: <0BC8D9FA-2822-41CA-8CAE-89DCF9C4918F@dsl-only.net> Date: Mon, 28 Nov 2016 03:02:18 -0800 Cc: Dimitry Andric , Ed Maste , Justin Hibbits , Nathan Whitehorn To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 11:02:22 -0000 [The powerpc64 self-hosted buildworld failure is for undefined references to llvm::sys::CompareAndSwap and llvm::sys::MemoryFence. See later below.] I cross built TARGET_ARCH=3Dpowerpc64 head -r309179 via . . . (has workaround matching -r309201 and my PowerMac G5 booting hack) buildworld via clang 3.9.0 and it using powerpc64-binutils buildkernel via powerpc-xtoolchain-gcc (and so powerpc64-binutils) and installed and booted the combination: > # uname -apKU > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r309179M: Mon Nov = 28 01:23:26 PST 2016 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain_kernel/powerpc.powerpc= 64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200017 1200017 > # clang --version > FreeBSD clang version 3.9.0 (tags/RELEASE_390/final 280324) (based on = LLVM 3.9.0) > Target: powerpc64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin I then attempted a self-hosted buildworld but it failed with: > Building = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full > --- clang-tblgen.full --- > = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a(ManagedStatic.o): = In function `getManagedStaticMutex()': > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1c4): = undefined reference to `llvm::sys::CompareAndSwap(unsigned int = volatile*, unsigned int, unsigned int)' > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1d8): = undefined reference to `llvm::sys::MemoryFence()' > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x220): = undefined reference to `llvm::sys::MemoryFence()' > clang++: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [clang-tblgen.full] Error code 1 >=20 > make[3]: stopped in /usr/src/usr.bin/clang/clang-tblgen > .ERROR_TARGET=3D'clang-tblgen.full' > = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc= .powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.ful= l.meta' > .MAKE.LEVEL=3D'3' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > .CURDIR=3D'/usr/src/usr.bin/clang/clang-tblgen' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc6= 4/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen' > .TARGETS=3D'all' > DESTDIR=3D'' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'powerpc' > MACHINE_ARCH=3D'powerpc64' > = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc= .powerpc64/usr/src/tmp' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20160818' > = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/u= sr/src/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/= powerpc.powerpc64/usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_= altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/bin:/sbin:/bin:/usr= /sbin:/usr/bin' > SRCTOP=3D'/usr/src' > = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64= /usr/src/tmp/usr/src' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.powerpc64= -host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/usr.bin/clang/clang-tblgen/Makefile = /usr/src/usr.bin/clang/llvm.prog.mk /usr/src/lib/clang/llvm.pre.mk = /usr/src/lib/clang/llvm.build.mk /usr/src/tools/build/mk/bsd.prog.mk = /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk = /usr/src/usr.bin/clang/clang-tblgen/../Makefile.inc = /usr/src/usr.bin/clang/clang-tblgen/../../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk = /usr/src/tools/build/mk/Makefile.boot' > .PATH=3D'. /usr/src/usr.bin/clang/clang-tblgen = /usr/src/contrib/llvm/tools/clang/utils/TableGen' > 1 error . . . > # less = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full.meta > # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full.meta > CMD /usr/bin/clang++ -B /usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /tmp/usr/src/lib/clang/libllvm -I/usr/src/lib/clang/include = -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD = -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd12.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64-unknown-freebsd12.0\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/powerpc64vtsc_clang_altbinutils_world/power= pc.powerpc64/usr/src/tmp\" -g -Qunused-arguments = -I/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /tmp/legacy/usr/include -std=3Dc++11 -fno-exceptions -fno-rtti = -stdlib=3Dlibc++ -Wno-c++11-extensions -static = -L/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /tmp/legacy/usr/lib -o clang-tblgen.full ClangASTNodesEmitter.o = ClangAttrEmitter.o ClangCommentCommandInfoEmitter.o = ClangCommentHTMLNamedCharacterReferenceEmitter.o = ClangCommentHTMLTagsEmitter.o ClangDiagnosticsEmitter.o = ClangSACheckersEmitter.o NeonEmitter.o TableGen.o = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a -lncursesw = -lpthread -legacy > CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen > TARGET clang-tblgen.full > -- command output -- > = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a(ManagedStatic.o): = In function `getManagedStaticMutex()': > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1c4): = undefined reference to `llvm::sys::CompareAndSwap(unsigned int = volatile*, unsigned int, unsigned int)' > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1d8): = undefined reference to `llvm::sys::MemoryFence()' > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x220): = undefined reference to `llvm::sys::MemoryFence()' > clang++: error: linker command failed with exit code 1 (use -v to see = invocation) > *** Error code 1 . . . > # svnlite info /usr/src/ | grep "Re[lpv]" > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 309179 > Last Changed Rev: 309179 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Nov 28 11:52:14 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B514C59578 for ; Mon, 28 Nov 2016 11:52:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3F311CF0 for ; Mon, 28 Nov 2016 11:52:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1598 invoked from network); 28 Nov 2016 11:52:16 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Nov 2016 11:52:16 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Mon, 28 Nov 2016 06:52:18 -0500 (EST) Received: (qmail 4486 invoked from network); 28 Nov 2016 11:52:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Nov 2016 11:52:18 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3C8EDEC7B39; Mon, 28 Nov 2016 03:52:11 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation Message-Id: Date: Mon, 28 Nov 2016 03:52:10 -0800 Cc: Justin Hibbits , Nathan Whitehorn To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 11:52:14 -0000 [To get this far I had to use WERROR=3D to get past other C/C++ = rejections.] Below are some example errors that clang 3.9.0 reports for trying to handle the assembler notations that are used: --- hwpmc_e500.o --- /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 3,400 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, pmgc0); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic pmc_pmlc =3D mfpmr(PMR_PMLCa0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 10,144 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:410:3: error: = unrecognized instruction mnemonic mtpmr(PMR_PMLCa0, pmc_pmlc); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 144,10 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:413:14: error: = unrecognized instruction mnemonic pmc_pmlc =3D mfpmr(PMR_PMLCa1); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 10,145 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:415:3: error: = unrecognized instruction mnemonic mtpmr(PMR_PMLCa1, pmc_pmlc); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 145,10 ^ =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Nov 29 22:47:02 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D8A5C5C669 for ; Tue, 29 Nov 2016 22:47:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02A7F19EA for ; Tue, 29 Nov 2016 22:47:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17977 invoked from network); 29 Nov 2016 21:46:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Nov 2016 21:46:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Tue, 29 Nov 2016 16:47:08 -0500 (EST) Received: (qmail 10000 invoked from network); 29 Nov 2016 21:47:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Nov 2016 21:47:07 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 64CCCEC8F93; Tue, 29 Nov 2016 13:47:00 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? Message-Id: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> Date: Tue, 29 Nov 2016 13:46:59 -0800 Cc: Dimitry Andric To: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 22:47:02 -0000 I experiment with finding issues with using clang as the FreeBSD system compiler for TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 . I = report what I find, including to llvm's bugzilla. The following questions are driven by that but likely apply to other contexts. Summary: Does using clang 3.9.0 as the system compiler imply one should = or must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work? Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria for what dwarfdump should show for the exception information (if the information to be shown is to be correct/sufficient for libunwind)? Your answer's detail might indicate that I've misdirected the llvm folks in submittals like https://llvm.org/bugs/show_bug.cgi?id=3D26844 . There is also the question of if/when llvm's libunwind is ready to be = used for powerpc64 or powerpc (or . . .) if there are architecture specifics involved. That answer might determine when C++ exceptions work (and so when devel/kyua might have a chance to work) and is sort of separate = from the main question here but is still of interest overall. Should powerpc64 and powerpc clang 3.9.0 testing be using WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? https://llvm.org/bugs/show_bug.cgi?id=3D26844 has some of my notes about clang's output not matching what is now the WITHOUT_LLVM_LIBUNWIND context. My notes have been extended to head -r309179's clang 3.9.0 for powerpc64. Even: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } on powerpc64 when compiled by clang 3.9.0 from a TARGET_ARCH=3Dpowerpc64 buildworld that was built by clang 3.9.0 (an implicitly WITHOUT_LLVM_LIBUNWIND ) crashes with: Program terminated with signal SIGABRT, Aborted. #0 0x00000000502f8868 in .__sys_thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x00000000502f8868 in .__sys_thr_kill () from /lib/libc.so.7 #1 0x00000000502f8818 in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 #2 0x00000000502f8748 in abort () at = /usr/src/lib/libc/stdlib/abort.c:65 #3 0x00000000501c9cbc in _Unwind_GetGR (context=3D, = index=3D65) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:180 #4 uw_update_context_1 (context=3D, fs=3D) at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1353 #5 0x00000000501c78b0 in uw_init_context_1 (context=3D0xffffffffffffd1e0,= outer_cfa=3D0xffffffffffffd940, outer_ra=3D0x50179ea0 = <__cxa_throw(void*, std::type_info*, void (*)(void*))+248>) at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1442 #6 0x00000000501c7418 in _Unwind_RaiseException (exc=3D) = at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:92 #7 0x0000000050179ea0 in throw_exception (ex=3D) at = /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:774 #8 __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at = /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:801 #9 0x0000000010000cf0 in .main () (gdb) up 3 =20 #3 0x00000000501c9cbc in _Unwind_GetGR (context=3D, = index=3D65) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:180 180 gcc_assert (size =3D=3D sizeof(_Unwind_Word)); (gdb) list 175 /* This will segfault if the register hasn't been saved. */ 176 if (size =3D=3D sizeof(_Unwind_Ptr)) 177 return * (_Unwind_Ptr *) ptr; 178 else 179 { 180 gcc_assert (size =3D=3D sizeof(_Unwind_Word)); 181 return * (_Unwind_Word *) ptr; 182 } 183 } (Absent the assert it might have gotten SIGSEGV.) My notes to llvm have dwarfdump output and words about what it shows relative to what gcc shows for the likes of _Unwind_RaiseException . I also show what Unbuntu Mate 16.10 has. But are the comparisons I made appropriate since they are based implicitly on WITHOUT_LLVM_LIBUNWIND ? Note: Now that the code generation has the registers and stack handling for powerpc64 in the area no longer stomping on or mis assigning the pointers to stack frames the exceptions oddities are easier to look at: gdb can actually report correctly for bt. I'll need to be explicit about WITHOUT_LLVM_LIBUNWIND vs. WITH_LLVM_LIBUNWIND on llvm's bugzilla in the future. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Nov 29 22:57:08 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 993E2C5CB65; Tue, 29 Nov 2016 22:57:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D71C1F90; Tue, 29 Nov 2016 22:57:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-qt0-x243.google.com with SMTP id n34so17515662qtb.3; Tue, 29 Nov 2016 14:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fjQmshotrYKNYXTZ80MXDPbKXCsouRk4OyJGmJyj4Sk=; b=Bqqi4BQbTycFm2UoC8Evd/ayF6ivK4/Btej/RmYkGdBZfUw2cQ+nZqYagEokB2MG6b MqCdYKQuz3J+NImRd/GGnt8kx4Yr6Vpthk7k9EIfQwgUADDMnSMo4ylWQyqiPA/PJCT+ QAMqpy0ru+5KoT5l0mt2+ODzQ8pLDbVgeTOPZYV16XxFn4ajVJeOyY0pNJdFJHgrsx4h y151z6mt2hK6ypD7gUT71yTDfN5jj6L/xmu0lmTfFyLH1PcFi+kQO0yvwBjzFBETSZv7 3UTWKaeda9v36QeFcRHIZS+HUg8a0mAlRD8/V6gqrl7b4Nw8KmZq8PyYF89aC7tVyIHv 57BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fjQmshotrYKNYXTZ80MXDPbKXCsouRk4OyJGmJyj4Sk=; b=FN6OenOEmZgHfFZoYuWh/OcE3bTPwna5LOdP6d6q2VuSSaBRjrLYLJimNOHkkS+YYy vEnThTkckZlI2XPt8md5B1jp0KS1yRii5REh2EvKbQRf7Qr+yUqKVSVcm32j7RqCIbJo npySKXhjhcuTw+DgEnHOs1iHXVDXF0L5Fv8lRurQW540SWjGbjjw90fgCQJSHVfq2pZW 0sVpjG61L7FFEKjY3DPcGs4oGhq5OHZAv2dvq5qfpfHBuBAjQw3q/bmUOoT19bhJjSOP BDMQzaaw2Vi2vn0yBshNr1sN4NOjH6xt7OQ98vz5KU19L8okDgsdnreh67qk4L3QSgEI 7clg== X-Gm-Message-State: AKaTC03pxJERdL9r2yfKrh4SSC+kNpHkNoDW94Zldhe241nROn3bFQOWGZveRlpEl1YZs310dcEv1KUZsFfVRA== X-Received: by 10.200.53.239 with SMTP id l44mr29330247qtb.60.1480460227355; Tue, 29 Nov 2016 14:57:07 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.12.132.163 with HTTP; Tue, 29 Nov 2016 14:56:46 -0800 (PST) In-Reply-To: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> From: Ed Maste Date: Tue, 29 Nov 2016 17:56:46 -0500 X-Google-Sender-Auth: tFQfJ-UAOCv2tw0Y9uLxQnXoPeo Message-ID: Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 22:57:08 -0000 On 29 November 2016 at 16:46, Mark Millard wrote: > > > Summary: Does using clang 3.9.0 as the system compiler imply one should or > must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work? > > Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria > for what dwarfdump should show for the exception information (if the > information to be shown is to be correct/sufficient for libunwind)? It does not. It should be possible to build a functional system both WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind data. Eventually new features may show up in Clang and LLVM's libunwind (and new versions of GNU's unwinder) that won't work with the old unwinder. > Your answer's detail might indicate that I've misdirected the llvm folks > in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 . > > There is also the question of if/when llvm's libunwind is ready to be used > for powerpc64 or powerpc (or . . .) if there are architecture specifics > involved. That answer might determine when C++ exceptions work (and so > when devel/kyua might have a chance to work) and is sort of separate from > the main question here but is still of interest overall. > > Should powerpc64 and powerpc clang 3.9.0 testing be using > WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, and ELF Tool Chain on all of our supported architectures. From owner-freebsd-ppc@freebsd.org Wed Nov 30 22:08:48 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E94EC5E673 for ; Wed, 30 Nov 2016 22:08:48 +0000 (UTC) (envelope-from gabriel.diaz@vgtelecomreports.com) Received: from smtp.vgtelecomreports.com (smtp.vgtelecomreports.com [202.0.103.19]) by mx1.freebsd.org (Postfix) with ESMTP id F2DB4198D for ; Wed, 30 Nov 2016 22:08:42 +0000 (UTC) (envelope-from gabriel.diaz@vgtelecomreports.com) X-SmarterMail-Authenticated-As: admin@vgtelecomreports.com DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; d=vgtelecomreports.com; s=smtp; h=received:from:to:message-id:subject:date:mime-version:reply-to :content-type; b=lwA/DzTSFtpUgNfNIbMovHfpYHc8urkckOBJ4+aXM4bNx46jksxsRDn1u/BOjc2qd ZEKIyKcYCzRF/1m2RCjrFQZNKk2dSjuQc/nzQCq1z7gbYqYNJqsui6gIcV8kS638g UGyiILcVibnwfRyl4KVXbqxt5pKTCemGqqYPF5FMk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vgtelecomreports.com; s=smtp; h= content-type:reply-to:mime-version:date:subject:message-id:to:from; bh=WJ1YhquiDApQyiCItD9dGfhhu/SfF90ed/l640fnIxU=; b=k5TQ3BszNxYpjDXC19e6pKIvIIinFJoaOLWshKtzNwHOtZKNh+Fo7cOdr7KUZepBl 254Kyq07Toiw0Wrcqe4j6fmeDvax6Uh5m1k3TE3pESDqWRRJgT1WV6lf4k2Ah3LA4 LTAz2dQjymPkQIHGijXu3k8H4WNQiZImpEhYnRRug= Received: from WIN-ASQ29B6R1EP (WIN-ASQ29B6R1EP [202.0.103.127]) by smtp.vgtelecomreports.com with SMTP; Wed, 30 Nov 2016 18:10:39 +0000 From: Gabriel Diaz To: freebsd-ppc@freebsd.org Message-Id: <20161130181039.-1158052454@vgtelecomreports.com> Subject: Next Generation Cyber Security Market Forecast Report 2016-2021 Date: Wed, 30 Nov 2016 18:10:39 +0000 MIME-Version: 1.0 Reply-To: gabriel.diaz@vgtelecomreports.com Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 22:08:48 -0000 Visiongain - Business Report Updates Speak to our consultant now: +44 (0)20 7549 9933 Next Generation Cyber Security Market Forecast Report 2016-2021 Companies Advancing Beyond Traditional Firewalls Towards Cloud Based & Big Data Solutions For The Internet of Things (IoT) The period 2016-2021 will see a meteoric rise in the market size of Next Generation Cyber Security. During this period, Next Generation Cyber Security will be one of the fastest growing segments of the Cyber sector. Global revenues will reach $35.7 billion in 2016 and will increase in size significantly from 2016 and 2021. The report analyses trends in the market both quantitatively and qualitatively. In recent years, this global Next Generation Cyber Security market has undergone a technological revolution with the rising sophistication of cyber-attacks. Next Generation Cyber Security is of increasing importance currently as both developed and developing nations becomes underlined by threats from hackers. How this 209 page report delivers: • Global Next Generation Cyber Security market forecasts from 2016-2021 • Regional Next Generation Cyber Security market forecasts from 2016-2021 covering Asia-Pacific, Latin America, Europe, Middle East and Africa, and North America; • Country Next Generation Cyber Security forecasts from 2016-2021 covering China, the USA, Japan, France, the UK, Germany, India, Russia, Italy, Brazil & RoW • Next Generation Cyber Security submarket forecasts from 2016-2021 covering Application Security - Cloud Security - Content Security - Endpoint Security - Network Security • Analysis of the key factors driving growth in the global and regional/country level Next Generation Cyber Security markets from 2016-2021 • Profiles of the leading players and analysis of their prospects over the forecast period - BAE Systems - Barracuda Networks - Bay Dynamics - Cisco Systems - Check Point - FireEye - Fortinet - Herjavec Group - Hewlett Packard - Intel Corporation - Juniper Networks - Norse - Palo Alto Networks - Splunk - Watch Guard • Analysis of game changing technological trends being employed by the leading players and how these will shape the cyber security industry. • SWOT analysis of the major strengths and weaknesses of the market, together with the opportunities available and the key threats faced. • Market conclusions & recommendations. • 121 tables, charts and graphs that utilise visual representation in order to illustrate trends and market projections within the Next Generation Cyber Security market • 6 Full transcripts of exclusive Visiongain interviews with key opinion-leaders in the market, from the following companies: - Delve Labs - Digital Guardian - LogRhythm - Nymi - Sandstorm.io - Spikes Security For more information and order please contact gabriel.diaz@vgtelecomreports.com Select the license from the list below and send your details Licensing options: Single User GBP 1999 Dept. (5 Users) GBP 2999 Site GBP 4999 Global GBP 6999 Buy this report Want to know more? Send me more info Table of Contents - Next Generation Cyber Security Market Forecast Report 2016-2021 1. Report Overview 2. Introduction to the Next Generation Cyber Security Market 2.1 Next Generation Cyber Security Market Introduction 2.2 Assessing the Cyber Security Market Landscape 2.3 High Growth Rate Driving up the Next Generation Cyber Security Job and Skills Market 2.4 Next Generations Cyber Security Measures 2.5 Factors Driving the Next Generation Cyber Security Market 2.6 Cyber Security Threat Also Existing for Consumers 2.7 Competitive Ecosystem in the Next Generation Cyber Security Market 2.8 Trend Analysis of the Cyber Security Market 2.9 Why is Cyber Security So Important to Homeland Security? 2.10 What Does the Cyber Threat to Critical Infrastructure Encompass? 2.11 Intentions/Goals of Cyber Attack 2.12 Types of Cyber Attack 2.13 Methods of Cyber Defence 2.14 Notable Cyber Attacks & Incidents 2.14.1 Conficker 2.14.2 Operation Buckshot Yankee 2.14.3 Aurora 2.14.4 Chinese Diversion of Internet Traffic 2.14.5 Stuxnet 2.14.6 Duqu 2.14.7 RSA 2.14.8 Sony Corporation 2.14.9 Operation Shady RAT 2.14.10 Mitsubishi Heavy Industries 2.14.11 Flame / Operation: Olympic Games 2.14.12 Aramco 2.14.13 The Navy and Marine Corps Intranet (NMCI) 2.14.14 Operation Saffron Rose 2.14.15 Operation Dragonfly 2.14.16 Norwegian Oil and Gas 2.14.17 Sony Picture Entertainment 2.14.18 Operation Cleaver 2.15 List of Recent Cyber Security Attacks 3. Global Next Generation Cyber Security Market 3.1 Market Definition 3.1.1 Application Security Submarket Definition 3.1.2 Cloud Security Submarket Definition 3.1.3 Content Security Submarket Definition 3.1.4 Endpoint Security Submarket Definition 3.1.5 Network Security Submarket Definition 3.2 Global Next Generation Cyber Security Market Forecast 2016-2021 4. Global Next Generation Cyber Security Submarket Forecasts 2016-2021 4.1 What are the Leading Submarkets in Next Generation Cyber Security Revenue Forecast 2016-2021? 4.1.1 Global Next Generation Cyber Security Revenue Submarket Forecast AGR & CAGR 4.1.2 Network Security Sector Leading the Next Generation Cyber Security with a Market Share of 38.1% In 2016 4.2 Next Generation Application Security 4.2.1 Next Generation Cyber Security Application Security Submarket Forecast Summary 2016-2021 4.3 Next Generation Cloud Security 4.3.1 Next Generation Cyber Security Cloud Security Submarket Forecast Summary 2016-2021 4.4 Next Generation Content Security 4.4.1 Next Generation Cyber Security Content Security Submarket Forecast Summary 2016-2021 4.5 Next Generation Endpoint Security 4.5.1 Next Generation Cyber Security Endpoint Security Submarket Forecast Summary 2016-2021 4.6 Next Generation Network Security 4.6.1 Next Generation Cyber Security Network Security Submarket Forecast Summary 2016-2021 5. Regional Next Generation Cyber Security Forecasts 2016-2021 5.1 Overview 5.2 North America Leading Region in Terms of Revenue in 2016 5.2.1 Regional Next Generation Cyber Security Revenue Forecast AGR & CAGR 5.2.2 North America Leading Regional Next Generation Cyber Security Market Shares in 2016 with 33.9% 5.3 Top 10 National Next Generation Cyber Security Market Forecasts 2016-2021 5.4 United States Next Generation Cyber Security Market Forecasts 2016-2021 5.4.1 US Cyber Security Market Drivers & Restraints 5.4.2 Changing Concerns: Why the focus on Next Generation Cyber Security will Continue to Drive US Homeland Security Expenditure Upwards 5.4.3 Investment in Next Generation From the Energy Sector 5.4.4 What are Domestic Airlines and the US Federal Aviation Authority Doing to Guard Against a Major Cyber Attack? 5.5 Chinese Next Generation Cyber Security Market Forecasts 2016-2021 5.5.1 Chinese Cyber Security Market Drivers & Restraints 5.5.2 Another Brick in the Great Firewall: How Has China’s Concern for the Control of Information Helped Shape its Defensive Cyber Posture? 5.5.3 A Digital Arms Race: How Strategic Competition with the United States Is Spurring on Chinese Ambitions to Become a Cyber Power 5.5.4 Recent Chinese Cyber Security Events 5.6 UK Next Generation Cyber Security Market Forecasts 2016-2021 5.6.1 U.K. Cyber Security Market Drivers & Restraints 5.7 Japan Next Generation Cyber Security Market Forecasts 2016-2021 5.7.1 Japanese Cyber Security Market Drivers & Restraints 5.7.2 What Measures Has Japan Taken To Boost It’s Cyber Security Capabilities And What Challenges Remain? 5.7.3 Recent Japanese Cyber Security Events 5.8 Germany Next Generation Cyber Security Market Forecasts 2016-2021 5.8.1 German Cyber Security Market Drivers & Restraints 5.8.2 Have German Cyber Security Efforts Acquired New Emphasis? 5.8.3 Recent German Cyber Security Events 5.9 France Next Generation Cyber Security Market Forecasts 2016-2021 5.9.1 French Cyber Security Market Drivers & Restraints 5.9.2 What is the Current State of French Cyber Security? 5.9.3 Recent French Cyber Security Events 5.10 Italy Next Generation Cyber Security Market Forecasts 2016-2021 5.10.1 Italian Cyber Security Market Drivers & Restraints 5.11 Russia Next Generation Cyber Security Market Forecasts 2016-2021 5.11.1 Russian Cyber Security Market Drivers & Restraints 5.11.2 Russian Cyber Security Policy: How Stage Two Has Built Upon Previous Developments 5.11.3 Recent Russian Cyber Security Events 5.12 Brazil Next Generation Cyber Security Market Forecasts 2016-2021 5.12.1 Brazilian Cyber Security Market Drivers & Restraints 5.13 India Next Generation Cyber Security Market Forecasts 2016-2021 5.13.1 Indian Cyber Security Market Drivers & Restraints 5.13.2 How Have Repeated Blackouts Placed a Renewed Emphasis on Indian Critical Infrastructure Protection? 5.13.3 How Will the Recommendations of the JWG Affect Indian Cyber Security? 5.13.4 Recent Indian Cyber Security Events 5.14 Rest of World Next Generation Cyber Security Market Forecasts 2016-2021 5.14.1 Rest of the World Cyber Security Market Drivers & Restraints 5.14.2 Recent Rest of the World Cyber Security Events 6. SWOT Analysis of the Next Generation Cyber Security Market 7. Expert Opinion 7.1 Delve Labs Interview 7.1.1 Delve Labs Company Background & Cyber Security Offerings 7.1.2 Delve Lab’s Strengths in the Cyber Security Sector 7.1.3 Defining Next Generation Cyber Security 7.1.4 Future of Cyber Security Industry 7.1.5 Trends and Factors Affecting Product Development or Implementation 7.1.6 Cyber Security Products and Solutions Clients Frequently Require 7.1.7 Cyber Security Sub-Markets Critical for Delve Lab’s Growth 7.1.8 Cyber Security Market Drivers and Restraints 7.1.9 Technological Development in the Cyber Security Industry and the Impact on Delve Lab 7.1.10 Strong Regional Cyber Security Markets of the Future 7.1.11 Regional Cyber Security Markets Critical to Delve Labs 7.1.12 Challenges & Opportunities in the Cyber Security Market 7.2 Digital Guardian Interview 7.2.1 Digital Guardian Company Background & Cyber Security Offerings 7.2.2 Digital Guardian’s Strengths in the Cyber Security Sector 7.2.3 Defining Next Generation Cyber Security 7.2.4 Future of Cyber Security Industry 7.2.5 Trends and Factors Affecting Product Development or Implementation 7.2.6 Cyber Security Products and Solutions Clients Frequently Require 7.2.7 Cyber Security Sub-Markets Critical for Digital Guardian’s Growth 7.2.8 Cyber Security Market Drivers and Restraints 7.2.9 Technological Development in the Cyber Security Industry and the Impact on Digital Guardian 7.2.10 Strong Regional Cyber Security Markets of the Future 7.2.11 Regional Cyber Security Markets Critical to Digital Guardian 7.2.12 Challenges & Opportunities in the Cyber Security Market 7.3 LogRhythm Interview 7.3.1 LogRhythm Company Background & Cyber Security Offerings 7.3.2 LogRhythm’s Strengths in the Cyber Security Sector 7.3.3 Defining Next Generation Cyber Security 7.3.4 Trends and Factors Affecting Product Development or Implementation 7.3.5 Cyber Security Products and Solutions Clients Frequently Require 7.3.6 Cyber Security Market Drivers and Restraints 7.3.7 Challenges & Opportunities in the Cyber Security Market 7.4 Nymi Interview 7.4.1 Nymi Company Background & Cyber Security Offerings 7.4.2 Nymi’s Strengths in the Cyber Security Sector 7.4.3 Defining Next Generation Cyber Security 7.4.4 Future of Cyber Security Industry 7.4.5 Trends and Factors Affecting Product Development or Implementation 7.4.6 Cyber Security Products and Solutions Clients Frequently Require 7.4.7 Cyber Security Sub-Markets Critical for Nymi’s Growth 7.4.8 Cyber Security Market Drivers and Restraints 7.4.9 Technological Development in the Cyber Security Industry and the Impact on Nymi 7.4.10 Regional Cyber Security Markets Critical to Nymi 7.5 Sandstorm.io Interview 7.5.1 Sandstorm.io Company Background & Cyber Security Offerings 7.5.2 Sandstorm’s Strengths in the Cyber Security Sector 7.5.3 Sandstorm.io Views on the Next Generation Cyber Security Market 7.6 Spikes Security Interview 7.6.1 Spikes Security Company Background & Cyber Security Offerings 7.6.2 Spikes Security’s Strengths in the Cyber Security Sector 7.6.3 Defining Next Generation Cyber Security 7.6.4 Future of Cyber Security Industry 7.6.5 Trends and Factors Affecting Product Development or Implementation 7.6.6 Cyber Security Products and Solutions Clients Frequently Require 7.6.7 Cyber Security Sub-Markets Critical for Spikes Security’s Growth 7.6.8 Cyber Security Market Drivers and Restraints 7.6.9 Technological Development in the Cyber Security Industry and the Impact on Spikes Security 7.6.10 Strong Regional Cyber Security Markets of the Future 7.6.11 Regional Cyber Security Markets Critical to Spikes Security 7.6.12 Challenges & Opportunities in the Cyber Security Market 7.6.13 Final Thoughts on the Cyber Security Market 8. Significant Companies in the Next Generation Cyber Security Ecosystem 8.1 BAE Systems 8.1.1 BAE Systems Cyber Security Overview 8.1.2 BAE Systems Primary Market Competitors 8.1.3 BAE Systems SWOT Analysis 8.2 Barracuda Networks 8.2.1 Cyber Security Overview 8.2.2 Barracuda Networks Products 8.3 Bay Dynamics 8.3.1 Bay Dynamics Cyber Security Overview 8.4 Cisco Systems 8.4.1 Cisco Systems Cyber Security Overview 8.4.3 Cisco Systems Primary Market Competitors 8.4.4 Cisco Systems SWOT Analysis 8.5 Check Point 8.5.1 Cyber Security Overview 8.5.2 Check Point Primary Market Competitors 8.5.3 Check Point SWOT Analysis 8.6 FireEye 8.6.1 FireEye Latest developments 8.6.2 Challenges faced by FireEye 8.7 Fortinet 8.7.1 Fortinet Cyber Security Overview 8.7.3 Fortinet Primary Market Competitors 8.7.4 Fortinet SWOT Analysis 8.8 Herjavec Group 8.8.1 Overview of Herjavec Group’s Cyber Security Offerings 8.8.2 Recent Acquisition and Expansion into United Kingdom & Europe 8.9 Hewlett Packard 8.9.1 Hewlett Packard Company’s Role in the Cyber Security Market 8.9.2 Hewlett Packard Company’s Organisational Structure 8.9.3 Hewlett Packard Company’s Cyber Security Products 8.9.4 Hewlett Packard Company’s Primary Market Competitors 8.9.5 Hewlett Packard Company’s Recent M&A Activity 8.10 Intel Corporation 8.10.1 Intel Company Profile 8.10.2 Intel Primary Market Competitors 8.10.3 Intel SWOT Analysis 8.11 Juniper Networks 8.11.1 Recent Developments 8.11.2 Juniper Networks Partnerships and Ventures 8.11.3 Juniper Networks Products and Services 8.11.4 Juniper Networks Future Outlook 8.12 Norse 8.12.1 Norse Latest Developments 8.13 Palo Alto Networks 8.13.1 Palo Alto Networks Latest Developments 8.14 Splunk 8.14.1 Cyber Security Overview 8.14.2 Splunk Recent Developments 8.14.3 Splunk Products and Services 8.14.4 Splunk Partnerships 8.14.5 Splunk Future Outlook 8.15 Watch Guard 8.15.1 Watch Guard Recent Developments 8.15.2 Watch Guard Products and services 8.15.3 Watch Guard Partnerships and Ventures 8.15.4 Watch Guard Future Outlook 9. Conclusion 9.1 Huge Potential for Growth in the Cyber Security Space 9.2 Regional Analysis of Next Generation Cyber Security Market Growth 9.3 Cyber Security Vital to National Defence 9.4 Increasing Number of Cyber Attacks on Businesses 9.5 Analysing the Evolution of Traditional Cyber Security to Next Generation Cyber Security 9.6 Future Potential of Next Generation Cyber Security 10. Glossary List of Tables Table 2.1 Intentions/Goals of Cyber Attack (Type, Description) Table 2.2 Types of Cyber Attack (Type, Description) Table 2.3 Cyber Defence Systems (Method of Cyber Defence, Description) Table 2.4 Recent History of High Profile Cyber Attacks (Date, Description) Table 3.1 Global Next Generation Cyber Security Market Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 4.1 Global Next Generation Cyber Security Revenue Submarket Forecast 2016-2021 ($ billion) Table 4.2 Global Next Generation Cyber Security Revenue Submarket AGR Forecast 2017-2021 (AGR %) Table 4.3 Global Next Generation Cyber Security Revenue Submarket CAGR Forecast (%) 2016-2019, 2019-2021, and 2016-2021 Table 4.4 Global Next Generation Cyber Security Market Share Forecast by Type 2016-2021 (%) Table 4.5 Next Generation Cyber Security Application Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 4.6 Next Generation Cyber Security Cloud Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 4.7 Next Generation Cyber Security Content Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 4.8 Next Generation Cyber Security Endpoint Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 4.9 Next Generation Cyber Security Network Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.1 Regional Next Generation Cyber Security Revenue Forecast 2016-2021 ($ billion) Table 5.2 Regional Next Generation Cyber Security Revenue AGR Forecast 2017-2021 (AGR %) Table 5.3 Regional Next Generation Cyber Security Revenue CAGR Forecast (%) 2016-2019, 2019-2021, and 2016-2021 Table 5.4 Regional Next Generation Cyber Security Market Share Forecast 2016-2021 (%) Table 5.5 Top 10 National Next Generation Cyber Security Market Forecast 2016-2021 ($ Billions, AGR%, % Share) Table 5.6 US Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.8 China Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.9 Chinese Cyber Security Drivers & Restraints Table 5.10 UK Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.11 U.K. Cyber Security Market Drivers & Restraints Table 5.12 Japan Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.13 Japanese Cyber Security Market Drivers & Restraints Table 5.14 Germany Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.15 German Cyber Security Market Drivers & Restraints Table 5.16 France Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.17 French Cyber Security Market Drivers & Restraints Table 5.18 Italy Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.19 Italian Cyber Security Market Drivers & Restraints Table 5.20 Russia Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.21 Russian Cyber Security Market Drivers & Restraints Table 5.22 Brazil Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.23 Brazilian Cyber Security Market Drivers & Restraints Table 5.24 India Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.25 Indian Cyber Security Market Drivers & Restraints Table 5.26 RoW Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billion, AGR %, CAGR%, Cumulative) Table 5.27 Rest of the World Cyber Security Market Drivers & Restraints Table 6.1 SWOT Analysis of the Next Generation Cyber Security Market 2016 Table 8.1 Recent BAE Systems Cyber Security Contracts / Projects / Programmes (Date, Country, Value ($m), Details) Table 8.2 BAE Systems Selected Cyber Security Products & Services (Company Division, Product, Specification) Table 8.3 SWOT Analysis of BAE Systems 2015 Table 8.4 Barracuda Cyber Security Solutions Table 8.5 Recent Cisco Systems Cyber Security Contracts / Projects / Programmes (Date, Country, Value ($m), Details) Table 8.6 Cisco Systems Inc Selected Cyber-Security Products (Product/Service Name, Specification) Table 8.7 SWOT Analysis of Cisco Systems 2016 Table 8.8 Check Point Selected Cyber Security Products & Services (Product, Specification) Table 8.9 SWOT Analysis Check Point 2015 Table 8.10 Fortinet Major Cyber Security Contracts & Programmes 2013-2014 (Date, Country, Details) Table 8.11 Fortinet Selected Cyber Security Products & Services 2014 (Product, Specification) Table 8.12 SWOT Analysis of Fortinet 2015 Table 8.13 Overview of Herjavec Group’s Cyber Security Offerings Table 8.14 Herjavec’s core managed security services Table 8.15 Recent Hewlett Packard Company Cyber Security Contracts / Projects / Programmes (Date, Country, Value $m, Details) Table 8.16 Sample of Hewlett Packard Company’s Cyber Security Products / Services (Company Section, Product, Specifications) Table 8.17 Hewlett Packard Company Recent M&A Activity (Date, Details) Table 8.18 Intel Corporation Cyber-security (Product/Service Type, Company Division, Product/Service Name, Specification) Table 8.19 SWOT Analysis of Intel 2016 Table 8.20 Juniper Networks Products and Services Table 8.21 Splunk Products and Services List of Figures Figure 2.1 Operation Shady RAT Targets (Sector, Number of Targets) Figure 3.1 Next Generation Cyber Security Market Venn Diagram Representation Figure 3.2 Next Generation Cyber Security Sub-Market Segmentation Figure 3.3 Global Next Generation Cyber Security Market Forecast 2016-2021 ($ billion, AGR%) Figure 4.1 Global Next Generation Cyber Security Revenue Submarket Forecast 2016-2021 ($ billion) Figure 4.2 Global Next Generation Cyber Security Revenue Submarket AGR Forecast 2017-2021 (AGR %) Figure 4.3 Global Next Generation Cyber Security Market Share Forecast by Type 2016 (%) Figure 4.4 Global Next Generation Cyber Security Market Share Forecast by Type 2019 (%) Figure 4.5 Global Next Generation Cyber Security Market Share Forecast by Type 2021 (%) Figure 4.6 Next Generation Cyber Security Application Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR%) Figure 4.7 Next Generation Cyber Security Application Security Submarket Share Forecast 2016, 2019 and 2021 (% Share) Figure 4.8 Next Generation Cyber Security Cloud Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR%) Figure 4.9 Next Generation Cyber Security Cloud Security Submarket Share Forecast 2016, 2019 and 2021 (% Share) Figure 4.10 Next Generation Cyber Security Content Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR%) Figure 4.11 Next Generation Cyber Security Content Security Submarket Share Forecast 2016, 2019 and 2021 (% Share) Figure 4.12 Next Generation Cyber Security Endpoint Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR%) Figure 4.13 Next Generation Cyber Security Endpoint Security Submarket Share Forecast 2016, 2019 and 2021 (% Share) Figure 4.14 Next Generation Cyber Security Network Security Submarket Revenue Forecast 2016-2021 ($ billion, AGR%) Figure 4.15 Next Generation Cyber Security Network Security Submarket Share Forecast 2016, 2019 and 2021 (% Share) Figure 5.1 Regional Next Generation Cyber Security Revenue Forecast 2016-2021 ($ billion) Figure 5.2 Regional Next Generation Cyber Security Revenue AGR Forecast 2016-2021 (AGR%) Figure 5.3 Regional Next Generation Cyber Security Market Share Forecast 2016 (%) Figure 5.4 Regional Next Generation Cyber Security Market Share Forecast 2019 (%) Figure 5.5 Regional Next Generation Cyber Security Market Share Forecast 2021 (%) Figure 5.6 Top 10 National Next Generation Cyber Security Market Forecast 2016-2021 ($ Billions, AGR%, % Share) Figure 5.7 US Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.8 US Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.9 China Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.10 China Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.11 UK Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.12 UK Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.13 Japan Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.14 Japan Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.15 Germany Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.16 Germany Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.17 France Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.18 France Share of Global Next Generation Cyber Security Market Forecast 2016, 2021 and 2021 (% Share) Figure 5.19 Italy Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.20 Italy Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.21 Russia Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.22 Russia Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.23 Brazil Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.24 Brazil Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.25 India Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.26 Indian Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 5.27 RoW Next Generation Cyber Security Market Revenue Forecast 2016-2021 ($ billions, AGR%) Figure 5.27 RoW Share of Global Next Generation Cyber Security Market Forecast 2016, 2019 and 2021 (% Share) Figure 8.1 BAE Systems Organisational Structure of Cyber Security Divisions 2016 Figure 8.2 BAE Systems Primary Market Competitors Figure 8.3 Cisco Systems Organisational Structure of Cyber Security Divisions Figure 8.4 BAE Systems plc Primary Market Competitors Figure 8.5 Check Point Primary Market Competitors Figure 8.6 Fortinet Organisational Structure of Cyber Security Divisions Figure 8.7 Fortinet Primary Market Competitors Figure 8.8 Hewlett Packard Company’s Organisational Structure Figure 8.9 Hewlett Packard Primary Market Competitors Figure 8.10 Intel Organisational Structure of Cyber Security Divisions Figure 8.11 Intel Primary Market Competitors Figure 8.12 Watch Guard Data Loss Prevention and Automated Intelligence and Decision Making Framework Companies Mentioned in this Report Adobe Systems Altron Amazon Amazon Web Services (AWS) American Airlines AMSEC LLC Anthem Anthem Apple Autonomy Barracuda Networks Bay Dynamics Boeing Booz Allen Hamilton BorderWare Technologies British Aerospace (BAe) CACI International Checkpoint China Telecom Cisco Systems Clarent Corporation Cloudflare Code Green Networks Comcast Computer Sciences Corporation ConocoPhillips Cryptolocker CrySyS Lab CSC DELL Inc Delve Labs Digital Guardian Domino's Pizza Dtex Systems Easy Solutions Elderwood Group EMC Engility Extreme Networks ExxonMobil FASTNET Corporation Fireye Fortinet General Dynamics Corp General Electric Company plc (GEC) Global Technical Systems Google Herjavec Group Hewlett Packard Home Depot Honeywell Technology Solutions Horton Networks Huawei IBM IHI Corp. Industrial Defender Inc. Intel Interpath Communications Japan Airlines JP Morgan Chase Juniper Networks Kaspersky Lab Kawasaki Heavy Industries L-3 Services Inc Lockheed Martin LogRhythm Mandiant Marathon Oil Marconi Electronic Systems (MES) McAfee Microsoft Mitsubishi Heavy Industries Mt Gox Muthoot Fincorp Ltd NBC New York Times Norse Northrop Nymi Oracle Palo Alto Networks Primera Blue Cross Quick Heal Rackspace Raytheon Company Redstone Arsenal Rosoboronexport RSA Rusal Sabre Holdings SAIC Sandia National Laboratories Sandstorm.io Saudi Aramco Scientific Research Corporation SecureID Serco Silversky Sony Corporation Sony Entertainment Sourcefire Splunk Symantec Sysec Target Telefonica Telefónica Global Technology Thales Group The Learning Company Topface Trend Micro Tshinghua Tongfang TV5Monde UBS Verio Vertica Systems VINCI group Voltage Security Vu Security Watchguard Wells Fargo WorldTalk Corporation Yahoo Yahoo Japan For more information and order please contact gabriel.diaz@vgtelecomreports.com Terms and Conditions By replying to this e-mail submitting your order for this product you have agreed without limitation or qualification to be bound by and to comply with these Terms and Conditions. You agree that you will not fail to complete any transaction after submitting an order to purchase a product or submit any order to purchase a product where you do not intend to complete the transaction. Management Reports will only be sent on receipt of payment. Our mailing address is: 230 City Road. EC1V 2QY, London, UK. As a valued contact or customer, you are receiving this email with information that we believe will be relevant to you. If however, you wish to stop future messages you can unsubscribe from this list From owner-freebsd-ppc@freebsd.org Thu Dec 1 02:03:40 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8E23C5E35D for ; Thu, 1 Dec 2016 02:03:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-59.reflexion.net [208.70.210.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD2711E2 for ; Thu, 1 Dec 2016 02:03:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31653 invoked from network); 1 Dec 2016 02:04:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Dec 2016 02:04:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Wed, 30 Nov 2016 21:03:18 -0500 (EST) Received: (qmail 16671 invoked from network); 1 Dec 2016 02:03:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Dec 2016 02:03:18 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AD039EC9006; Wed, 30 Nov 2016 18:03:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: Mark Millard In-Reply-To: Date: Wed, 30 Nov 2016 18:03:32 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric Content-Transfer-Encoding: 7bit Message-Id: <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 02:03:40 -0000 On 2016-Nov-29, at 2:56 PM, Ed Maste wrote: > On 29 November 2016 at 16:46, Mark Millard wrote: >> >> >> Summary: Does using clang 3.9.0 as the system compiler imply one should or >> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work? >> >> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria >> for what dwarfdump should show for the exception information (if the >> information to be shown is to be correct/sufficient for libunwind)? > > It does not. It should be possible to build a functional system both > WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the > _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind > data. Good to know. Thanks. [As there are no clang-based powerpc64 linux builds to my knowledge the following uses amd64/x86_64 examples instead for comparisons.] What I see from "dwarfdump -v -v -F .../libgcc_s.so.1" for FreeBSD head -r309179 vs. what I see for the clang 3.8.0 based OpenMandriva Lx V3.0 leaves me a little worried: OpenMandriva Lx V3.0 is more like what I would expect for: _Unwind_RaiseException (9990 vs. c701) _Unwind_ForcedUnwind (a330 vs. c857) _Unwind_Resume (9fb0 vs. c927) _Unwind_Resume_or_Rethrow (2da0 vs. c9e4) (The numbers are just for my reference in finding the dwarfdump material.) By contrast FreeBSD has missing information from what I can tell. For these 4 routines only: OpenMandriva Lx has scratch registers listed (r0 and r1 from the set of normally volatile registers normally not listed). No other routines in libgcc_s.so.1 have this. FreeBSD has no such extra registers listed anywhere, including not on the 4 where I'd expect them. Using _Unwind_RaiseException as an example of those 4 routines that I'm worried about. . . [Notes: r7 is %rsp, r6 is %rbp, r3 is %rbx, r2 is %rcx, r1 is %rdx, and r0 is %rax in amd64/x86_64 land. Only OpenMandriva Lx had examples of the last two. I use the dwarfdump naming below.] FreeBSD _Unwind_RaiseException: fde section offset 5328 0x000014d0 cie offset for fde: 5332 0x000014d4 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 16 (16 * 1) 9 DW_CFA_offset r3 -56 (7 * -8) 11 DW_CFA_offset r12 -48 (6 * -8) 13 DW_CFA_offset r13 -40 (5 * -8) 15 DW_CFA_offset r14 -32 (4 * -8) 17 DW_CFA_offset r15 -24 (3 * -8) 19 DW_CFA_nop 20 DW_CFA_nop 21 DW_CFA_nop 22 DW_CFA_nop All the registers referenced are very common: lots of routines having nothing to do with the Exception handling also list them. OpenMandriva Lx _Unwind_RaiseException: fde section offset 4280 0x000010b8 cie offset for fde: 4284 0x000010bc 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 8 (8 * 1) 9 DW_CFA_offset r15 -24 (3 * -8) 11 DW_CFA_offset r14 -32 (4 * -8) 13 DW_CFA_offset r13 -40 (5 * -8) 15 DW_CFA_offset r12 -48 (6 * -8) 17 DW_CFA_advance_loc 20 (20 * 1) 18 DW_CFA_offset r3 -56 (7 * -8) 20 DW_CFA_offset r1 -64 (8 * -8) 22 DW_CFA_offset r0 -72 (9 * -8) 24 DW_CFA_advance_loc2 284 27 DW_CFA_remember_state 28 DW_CFA_restore r6 29 DW_CFA_def_cfa r2 8 32 DW_CFA_advance_loc 4 (4 * 1) 33 DW_CFA_restore_state 34 DW_CFA_advance_loc 21 (21 * 1) 35 DW_CFA_def_cfa r7 8 38 DW_CFA_nop Note the lines for r1 and r0 that FreeBSD has no equivalent of: These are the Exception ABI's scratch registers usage that only apply to exception handling code that uses certain built-ins that imply the context. In normal routines r1 and r0 are volatile and so are not listed on OpenMandriva Lx. But FreeBSD never lists any scratch registers for the exception handing ABI, unlike the Itanium's standard that specified there are 4 --2 with predefined purposes. (Itanimum used GP15-GP18 for the exception handling scratch registers or something like that if I remember right.) So the amd64 FreeBSD information from clang 3.9.0 looks wrong to me unless the Itanium's standard is not the basis for what FreeBSD is doing here. NOTE: Analogous incorrectness with observed scratch register usage in builds based on clang 3.8.0 and clang 3.9.0 for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 are part of what I've reported as wrong to llvm for what blocks clang for them. In this context actual crashes from asserts or SIGSEGV during _Unwind_GetGR or _Unwind_SetGR for a scratch register's index is what started my investigation of the dwarfdump reports in the first place. I found the register information missing in the dwarfdump output and comments in the code about being such a missing status for any GR leading to what I had observed for references to that GR --and that is my interpretation of the code so commented as well. > Eventually new features may show up in Clang and LLVM's libunwind (and > new versions of GNU's unwinder) that won't work with the old unwinder. > >> Your answer's detail might indicate that I've misdirected the llvm folks >> in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 . >> >> There is also the question of if/when llvm's libunwind is ready to be used >> for powerpc64 or powerpc (or . . .) if there are architecture specifics >> involved. That answer might determine when C++ exceptions work (and so >> when devel/kyua might have a chance to work) and is sort of separate from >> the main question here but is still of interest overall. >> >> Should powerpc64 and powerpc clang 3.9.0 testing be using >> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? > > For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My > eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, > and ELF Tool Chain on all of our supported architectures. === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Dec 1 05:50:46 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C821C61702 for ; Thu, 1 Dec 2016 05:50:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-56.reflexion.net [208.70.210.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 113EF1671 for ; Thu, 1 Dec 2016 05:50:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3026 invoked from network); 1 Dec 2016 05:50:26 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Dec 2016 05:50:26 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 01 Dec 2016 00:50:50 -0500 (EST) Received: (qmail 30913 invoked from network); 1 Dec 2016 05:50:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Dec 2016 05:50:50 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8012DEC8FF8; Wed, 30 Nov 2016 21:50:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: Mark Millard In-Reply-To: <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> Date: Wed, 30 Nov 2016 21:50:37 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 05:50:46 -0000 [I add the dwarfdump -v -v -F /lib/libgcc_s.so.1 from 9.3-RELEASE -r268512 that does not agree with stable/11 -r309179's clang 3.9.0 content: it is like OpenMandriva Lx for the scratch register handling. I looked back this far because it was gcc 4.2.1 based for official amd64 releases.] On 2016-Nov-30, at 6:03 PM, Mark Millard wrote: > On 2016-Nov-29, at 2:56 PM, Ed Maste wrote: >=20 >> On 29 November 2016 at 16:46, Mark Millard = wrote: >>>=20 >>>=20 >>> Summary: Does using clang 3.9.0 as the system compiler imply one = should or >>> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions = work? >>>=20 >>> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same = criteria >>> for what dwarfdump should show for the exception information (if the >>> information to be shown is to be correct/sufficient for libunwind)? >>=20 >> It does not. It should be possible to build a functional system both >> WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the >> _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind >> data. >=20 > Good to know. Thanks. >=20 > [As there are no clang-based powerpc64 linux builds to my knowledge > the following uses amd64/x86_64 examples instead for comparisons.] >=20 > What I see from "dwarfdump -v -v -F .../libgcc_s.so.1" for FreeBSD > head -r309179 vs. what I see for the clang 3.8.0 based OpenMandriva > Lx V3.0 leaves me a little worried: OpenMandriva Lx V3.0 is more > like what I would expect for: >=20 > _Unwind_RaiseException (9990 vs. c701) > _Unwind_ForcedUnwind (a330 vs. c857) > _Unwind_Resume (9fb0 vs. c927) > _Unwind_Resume_or_Rethrow (2da0 vs. c9e4) >=20 > (The numbers are just for my reference in finding the dwarfdump > material.) >=20 > By contrast FreeBSD has missing information from what I can tell. >=20 > For these 4 routines only: OpenMandriva Lx has scratch registers > listed (r0 and r1 from the set of normally volatile registers > normally not listed). No other routines in libgcc_s.so.1 have > this. FreeBSD has no such extra registers listed anywhere, > including not on the 4 where I'd expect them. >=20 > Using _Unwind_RaiseException as an example of those 4 routines > that I'm worried about. . . >=20 > [Notes: r7 is %rsp, r6 is %rbp, r3 is %rbx, r2 is %rcx, r1 is %rdx, > and r0 is %rax in amd64/x86_64 land. Only OpenMandriva Lx had > examples of the last two. I use the dwarfdump naming below.] >=20 > FreeBSD _Unwind_RaiseException: >=20 > fde section offset 5328 0x000014d0 cie offset for fde: 5332 0x000014d4 > 0 DW_CFA_advance_loc 1 (1 * 1) > 1 DW_CFA_def_cfa_offset 16 > 3 DW_CFA_offset r6 -16 (2 * -8) > 5 DW_CFA_advance_loc 3 (3 * 1) > 6 DW_CFA_def_cfa_register r6 > 8 DW_CFA_advance_loc 16 (16 * 1) > 9 DW_CFA_offset r3 -56 (7 * -8) > 11 DW_CFA_offset r12 -48 (6 * -8) > 13 DW_CFA_offset r13 -40 (5 * -8) > 15 DW_CFA_offset r14 -32 (4 * -8) > 17 DW_CFA_offset r15 -24 (3 * -8) > 19 DW_CFA_nop > 20 DW_CFA_nop > 21 DW_CFA_nop > 22 DW_CFA_nop [It may be that some sort of update after 9.x makes what I report below expected. If so I've not identified it yet. At this point that is my guess: a different amd64 ABI now than in 9.3 for C++ exception handling, at least for some details.] The amd64 9.3-RELEASE -r268512 dwarfdump output for its _Unwind_RaiseException in its /lib/libgcc_s.so.1 does not match the above from stable/11 -r309179 for the scratch register handling. Note the r0 and r1 items (20 and 22): fde section offset 2672 0x00000a70 cie offset for fde: 2676 0x00000a74 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 13 (13 * 1) 9 DW_CFA_offset r3 -56 (7 * -8) 11 DW_CFA_offset r12 -48 (6 * -8) 13 DW_CFA_offset r13 -40 (5 * -8) 15 DW_CFA_offset r14 -32 (4 * -8) 17 DW_CFA_offset r15 -24 (3 * -8) 19 DW_CFA_advance_loc 9 (9 * 1) 20 DW_CFA_offset r0 -72 (9 * -8) 22 DW_CFA_offset r1 -64 (8 * -8) 24 DW_CFA_nop 25 DW_CFA_nop 26 DW_CFA_nop 27 DW_CFA_nop 28 DW_CFA_nop 29 DW_CFA_nop 30 DW_CFA_nop The 9.3 code has %rdx (r2) and %rax (r0) saved and restored: 00000000000088d0 <_Unwind_RaiseException> push %rbp 00000000000088d1 <_Unwind_RaiseException+0x1> mov %rsp,%rbp 00000000000088d4 <_Unwind_RaiseException+0x4> push %r15 00000000000088d6 <_Unwind_RaiseException+0x6> lea 0x10(%rbp),%rsi 00000000000088da <_Unwind_RaiseException+0xa> push %r14 00000000000088dc <_Unwind_RaiseException+0xc> push %r13 00000000000088de <_Unwind_RaiseException+0xe> push %r12 00000000000088e0 <_Unwind_RaiseException+0x10> push %rbx 00000000000088e1 <_Unwind_RaiseException+0x11> lea -0x3a0(%rbp),%rbx 00000000000088e8 <_Unwind_RaiseException+0x18> push %rdx 00000000000088e9 <_Unwind_RaiseException+0x19> push %rax . . . (the code here freely assigns to and uses %rdx and %rax) . . . . . . (also there are multiple return paths with differing properties) . = . . 00000000000089a3 <_Unwind_RaiseException+0xd3> mov -0x28(%rbp),%rbx 00000000000089a7 <_Unwind_RaiseException+0xd7> mov -0x20(%rbp),%r12 00000000000089ab <_Unwind_RaiseException+0xdb> mov -0x18(%rbp),%r13 00000000000089af <_Unwind_RaiseException+0xdf> mov -0x10(%rbp),%r14 00000000000089b3 <_Unwind_RaiseException+0xe3> mov -0x8(%rbp),%r15 00000000000089b7 <_Unwind_RaiseException+0xe7> leaveq=20 00000000000089b8 <_Unwind_RaiseException+0xe8> retq =20 . . . (Note the lack of restoring %rax above and the normal %rbp/%rsp restore: leaveq) . . . . . . (before the below involves _Unwind_Backtrace that the above did not) . . . 0000000000008a33 <_Unwind_RaiseException+0x163> lea = 0x8(%rbp,%rcx,1),%rcx 0000000000008a38 <_Unwind_RaiseException+0x168> mov -0x38(%rbp),%rax 0000000000008a3c <_Unwind_RaiseException+0x16c> mov -0x30(%rbp),%rdx 0000000000008a40 <_Unwind_RaiseException+0x170> mov -0x28(%rbp),%rbx 0000000000008a44 <_Unwind_RaiseException+0x174> mov -0x20(%rbp),%r12 0000000000008a48 <_Unwind_RaiseException+0x178> mov -0x18(%rbp),%r13 0000000000008a4c <_Unwind_RaiseException+0x17c> mov -0x10(%rbp),%r14 0000000000008a50 <_Unwind_RaiseException+0x180> mov -0x8(%rbp),%r15 0000000000008a54 <_Unwind_RaiseException+0x184> mov 0x0(%rbp),%rbp 0000000000008a58 <_Unwind_RaiseException+0x188> mov %rcx,%rsp 0000000000008a5b <_Unwind_RaiseException+0x18b> retq . . . (Note the abnormal %rbp/%rsp restore above) . . . No other routine in 9.3's /lib/libgcc_s.so.1 pushes or pops either of %rdx or %rax: only _Unwind_RaiseException. The code structure allows executing exception landing-pad code and such during the exception handling with the 2 registers used to provide context. The stable/11 -r309179 code for _Unwind_RaiseException does not have those scratch registers saved and restored and has some other basic differences for related aspects: 0000000000009990 <_Unwind_RaiseException> push %rbp 0000000000009991 <_Unwind_RaiseException+0x1> mov %rsp,%rbp 0000000000009994 <_Unwind_RaiseException+0x4> push %r15 0000000000009996 <_Unwind_RaiseException+0x6> push %r14 0000000000009998 <_Unwind_RaiseException+0x8> push %r13 000000000000999a <_Unwind_RaiseException+0xa> push %r12 000000000000999c <_Unwind_RaiseException+0xc> push %rbx 000000000000999d <_Unwind_RaiseException+0xd> sub $0x418,%rsp . . . (the code here freely assigns to and uses %rdx and %rax) . . . 0000000000009c61 <_Unwind_RaiseException+0x2d1> add $0x418,%rsp 0000000000009c68 <_Unwind_RaiseException+0x2d8> pop %rbx 0000000000009c69 <_Unwind_RaiseException+0x2d9> pop %r12 0000000000009c6b <_Unwind_RaiseException+0x2db> pop %r13 0000000000009c6d <_Unwind_RaiseException+0x2dd> pop %r14 0000000000009c6f <_Unwind_RaiseException+0x2df> pop %r15 0000000000009c71 <_Unwind_RaiseException+0x2e1> pop %rbp 0000000000009c72 <_Unwind_RaiseException+0x2e2> retq No code in the stable/11 libgcc_s.so.1 has a "push %rdx", but lots of code there has a "push %rax". The only means by which _Unwind_RaiseException's %rsp is restored/"popped" is also very different for stable/11's code compared to the 2nd of the 9.3 code paths for returning: stable/11 seems to not have any match analogous to that path. The differences seem too large to be the same ABI when things seem to be working. (Although I've not tried 9.3 application code that uses C++ exceptions under stable/11 : old stuff could fail if well tested for all I know.) I've not looked at amd64 10.x yet. > All the registers referenced are very common: lots of routines > having nothing to do with the Exception handling also list them. >=20 > OpenMandriva Lx _Unwind_RaiseException: >=20 > fde section offset 4280 0x000010b8 cie offset for fde: 4284 0x000010bc > 0 DW_CFA_advance_loc 1 (1 * 1) > 1 DW_CFA_def_cfa_offset 16 > 3 DW_CFA_offset r6 -16 (2 * -8) > 5 DW_CFA_advance_loc 3 (3 * 1) > 6 DW_CFA_def_cfa_register r6 > 8 DW_CFA_advance_loc 8 (8 * 1) > 9 DW_CFA_offset r15 -24 (3 * -8) > 11 DW_CFA_offset r14 -32 (4 * -8) > 13 DW_CFA_offset r13 -40 (5 * -8) > 15 DW_CFA_offset r12 -48 (6 * -8) > 17 DW_CFA_advance_loc 20 (20 * 1) > 18 DW_CFA_offset r3 -56 (7 * -8) > 20 DW_CFA_offset r1 -64 (8 * -8) > 22 DW_CFA_offset r0 -72 (9 * -8) > 24 DW_CFA_advance_loc2 284 > 27 DW_CFA_remember_state > 28 DW_CFA_restore r6 > 29 DW_CFA_def_cfa r2 8 > 32 DW_CFA_advance_loc 4 (4 * 1) > 33 DW_CFA_restore_state > 34 DW_CFA_advance_loc 21 (21 * 1) > 35 DW_CFA_def_cfa r7 8 > 38 DW_CFA_nop >=20 > Note the lines for r1 and r0 that FreeBSD has no > equivalent of: These are the Exception ABI's > scratch registers usage that only apply to exception > handling code that uses certain built-ins that > imply the context. In normal routines r1 and r0 are > volatile and so are not listed on OpenMandriva Lx. >=20 > But FreeBSD never lists any scratch registers for the > exception handing ABI, unlike the Itanium's standard > that specified there are 4 --2 with predefined > purposes. (Itanimum used GP15-GP18 for the exception > handling scratch registers or something like that if > I remember right.) >=20 > So the amd64 FreeBSD information from clang 3.9.0 looks > wrong to me unless the Itanium's standard is not the > basis for what FreeBSD is doing here. >=20 > NOTE: Analogous incorrectness with observed scratch > register usage in builds based on clang 3.8.0 and > clang 3.9.0 for TARGET_ARCH=3Dpowerpc and > TARGET_ARCH=3Dpowerpc64 are part of what I've reported > as wrong to llvm for what blocks clang for them. In > this context actual crashes from asserts or SIGSEGV > during _Unwind_GetGR or _Unwind_SetGR for a scratch > register's index is what started my investigation of > the dwarfdump reports in the first place. I found > the register information missing in the dwarfdump > output and comments in the code about being such a > missing status for any GR leading to what I had > observed for references to that GR --and that is > my interpretation of the code so commented as well. >=20 >=20 >> Eventually new features may show up in Clang and LLVM's libunwind = (and >> new versions of GNU's unwinder) that won't work with the old = unwinder. >>=20 >>> Your answer's detail might indicate that I've misdirected the llvm = folks >>> in submittals like https://llvm.org/bugs/show_bug.cgi?id=3D26844 . >>>=20 >>> There is also the question of if/when llvm's libunwind is ready to = be used >>> for powerpc64 or powerpc (or . . .) if there are architecture = specifics >>> involved. That answer might determine when C++ exceptions work (and = so >>> when devel/kyua might have a chance to work) and is sort of separate = from >>> the main question here but is still of interest overall. >>>=20 >>> Should powerpc64 and powerpc clang 3.9.0 testing be using >>> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? >>=20 >> For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My >> eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, >> and ELF Tool Chain on all of our supported architectures. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Dec 1 10:40:03 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC48CC60BE0 for ; Thu, 1 Dec 2016 10:40:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-60.reflexion.net [208.70.210.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70AAD1CD6 for ; Thu, 1 Dec 2016 10:40:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9831 invoked from network); 1 Dec 2016 10:39:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Dec 2016 10:39:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 01 Dec 2016 05:40:12 -0500 (EST) Received: (qmail 7214 invoked from network); 1 Dec 2016 10:40:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Dec 2016 10:40:12 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B8AA8EC8FF8; Thu, 1 Dec 2016 02:40:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: Mark Millard In-Reply-To: <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> Date: Thu, 1 Dec 2016 02:39:59 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 10:40:03 -0000 [A top-post noting that it is head -r309179 that is different from 9.3-RELELASE for _Unwind_raiseException --and from stable/11 -r309125-- after noting my repeated "stable/11" references that should have said "head". Also for code that uses libgcc_s.so.1 for C++ exception handling the odd one is instead stable/11 that is not like the other two.] First a correction to a systematic typing error: -r309179 was correct but it is head, not stable/11 . I repeat: My earlier comparison was between amd64 9.3-RELEASE and amd64 12-CURRENT -r309179 . What of stable/11 (by default WITHOUT_LLVM_LIBUNWIND=3D ) vs. head (by default WITH_LLVM_LIBUNWIND=3D ) --and both of those vs. release/9.3.0 (implicitly WITHOUT_LLVM_LIBUNWIND=3D )? First _Unwind_RaiseException as an example from inside libgc_s.so.1 for exception handling. . . head -r309179 does *not* match stable/11 -r309125 or release/9.3.0 . stable/11 -r309125 is more like release/9.3.0 . So head *has* changed the amd64 C++ exception handling details as far as I can tell: WITH_LLVM_LIBUNWIND changes things. A quick report below for stable/11 -r309125 shows it has both styles of returns, like release/9.3.0 does. It has r0 and r1 saved and restored too. stable/11 -r309125 _Unwind_RaiseException's code has: 0000000000002cb0 <_Unwind_RaiseException> push %rbp 0000000000002cb1 <_Unwind_RaiseException+0x1> mov %rsp,%rbp 0000000000002cb4 <_Unwind_RaiseException+0x4> push %r15 0000000000002cb6 <_Unwind_RaiseException+0x6> push %r14 0000000000002cb8 <_Unwind_RaiseException+0x8> push %r13 0000000000002cba <_Unwind_RaiseException+0xa> push %r12 0000000000002cbc <_Unwind_RaiseException+0xc> push %rbx 0000000000002cbd <_Unwind_RaiseException+0xd> push %rdx 0000000000002cbe <_Unwind_RaiseException+0xe> push %rax 0000000000002cbf <_Unwind_RaiseException+0xf> sub $0x368,%rsp . . . [ the below is mostly like the 2nd 9.3 return path ] 0000000000002e2b <_Unwind_RaiseException+0x17b> lea = 0x8(%rbp,%rax,1),%rcx 0000000000002e30 <_Unwind_RaiseException+0x180> add $0x368,%rsp 0000000000002e37 <_Unwind_RaiseException+0x187> pop %rax 0000000000002e38 <_Unwind_RaiseException+0x188> pop %rdx 0000000000002e39 <_Unwind_RaiseException+0x189> pop %rbx 0000000000002e3a <_Unwind_RaiseException+0x18a> pop %r12 0000000000002e3c <_Unwind_RaiseException+0x18c> pop %r13 0000000000002e3e <_Unwind_RaiseException+0x18e> pop %r14 0000000000002e40 <_Unwind_RaiseException+0x190> pop %r15 0000000000002e42 <_Unwind_RaiseException+0x192> pop %rbp 0000000000002e43 <_Unwind_RaiseException+0x193> mov %rcx,%rsp 0000000000002e46 <_Unwind_RaiseException+0x196> retq =20 [ the above really does update %rsp twice during the return sequence; the first of those updates is ineffective overall and is from not having set optimization explicitly ] [ the below is much like the first 9.3 return path ] 0000000000002e4a <_Unwind_RaiseException+0x19a> add $0x368,%rsp 0000000000002e51 <_Unwind_RaiseException+0x1a1> pop %rax 0000000000002e52 <_Unwind_RaiseException+0x1a2> pop %rdx 0000000000002e53 <_Unwind_RaiseException+0x1a3> pop %rbx 0000000000002e54 <_Unwind_RaiseException+0x1a4> pop %r12 0000000000002e56 <_Unwind_RaiseException+0x1a6> pop %r13 0000000000002e58 <_Unwind_RaiseException+0x1a8> pop %r14 0000000000002e5a <_Unwind_RaiseException+0x1aa> pop %r15 0000000000002e5c <_Unwind_RaiseException+0x1ac> pop %rbp 0000000000002e5d <_Unwind_RaiseException+0x1ad> retq =20 [Because of code order differences the above shows somewhat more than I did for 9.3 .] stable/11 -r309125 _Unwind_RaiseException's dwarfdump shows: fde section offset 720 0x000002d0 cie offset for fde: 724 0x000002d4 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 18 (18 * 1) 9 DW_CFA_offset r0 -72 (9 * -8) 11 DW_CFA_offset r1 -64 (8 * -8) 13 DW_CFA_offset r3 -56 (7 * -8) 15 DW_CFA_offset r12 -48 (6 * -8) 17 DW_CFA_offset r13 -40 (5 * -8) 19 DW_CFA_offset r14 -32 (4 * -8) 21 DW_CFA_offset r15 -24 (3 * -8) Note the r0 and r1 (and %rax and %rdx in the code) so it is like release/9.3.0 in that respect. (I've still not looked at 10.x and with 11 being as it is I might not bother.) What about programs that use libgcc_s.so.1 ? . . . Looking at an example program shows a code interface difference visible in that code. Look just before the __cxa_begin_catch@plt call in head vs. stable/11: head -r309179 has conditional code that stable/11 -r309125 does not: 0000000000400caf cmp $0x1,%edx 0000000000400cb2 jne 0000000000400cf3 (This has -O2 in use for both contexts.) head -r309179 has that conditional code: 0000000000400c90
push %rbp 0000000000400c91 mov %rsp,%rbp 0000000000400c94 push %rbx 0000000000400c95 push %rax 0000000000400c96 callq 000000000040093c 0000000000400c9b callq 000000000040093c 0000000000400ca0 callq 000000000040093c 0000000000400ca5 callq 0000000000400c50 <_Z1gv> 0000000000400caa jmp 0000000000400cac 0000000000400cac mov %rax,%rdi 0000000000400caf cmp $0x1,%edx 0000000000400cb2 jne 0000000000400cf3 0000000000400cb4 callq 000000000040097c = <__cxa_begin_catch@plt> 0000000000400cb9 mov %rax,%rbx 0000000000400cbc mov 0x20062e(%rip),%al # = 00000000006012f0 <_ZGVZ4mainE5eaddr> 0000000000400cc2 test %al,%al 0000000000400cc4 jne 0000000000400ce5 0000000000400cc6 mov $0x6012f0,%edi 0000000000400ccb callq 00000000004008fc = <__cxa_guard_acquire@plt> 0000000000400cd0 test %eax,%eax 0000000000400cd2 je 0000000000400ce5 0000000000400cd4 mov %rbx,0x20060d(%rip) # = 00000000006012e8 <_ZZ4mainE5eaddr> 0000000000400cdb mov $0x6012f0,%edi 0000000000400ce0 callq 000000000040092c = <__cxa_guard_release@plt> 0000000000400ce5 callq 000000000040096c = <__cxa_end_catch@plt> 0000000000400cea xor %eax,%eax 0000000000400cec add $0x8,%rsp 0000000000400cf0 pop %rbx 0000000000400cf1 pop %rbp 0000000000400cf2 retq =20 0000000000400cf3 callq 00000000004009ac = <_Unwind_Resume@plt> The call to _Unwind_Resume@plt above is another difference: stable/11 does not have that. stable/11 -r309125 does not have either of those points: 0000000000400be1 mov %rsp,%rbp 0000000000400be4 push %rbx 0000000000400be5 push %rax 0000000000400be6 callq 00000000004008bc 0000000000400beb callq 00000000004008bc 0000000000400bf0 callq 00000000004008bc 0000000000400bf5 callq 0000000000400ba0 <_Z1gv> 0000000000400bfa mov %rax,%rdi 0000000000400bfd callq 00000000004008fc = <__cxa_begin_catch@plt> 0000000000400c02 mov %rax,%rbx 0000000000400c05 mov 0x2006c5(%rip),%al # = 00000000006012d0 <_ZGVZ4mainE5eaddr> 0000000000400c0b test %al,%al 0000000000400c0d jne 0000000000400c2e 0000000000400c0f mov $0x6012d0,%edi 0000000000400c14 callq 000000000040087c = <__cxa_guard_acquire@plt> 0000000000400c19 test %eax,%eax 0000000000400c1b je 0000000000400c2e 0000000000400c1d mov %rbx,0x2006a4(%rip) # = 00000000006012c8 <_ZZ4mainE5eaddr> 0000000000400c24 mov $0x6012d0,%edi 0000000000400c29 callq 00000000004008ac = <__cxa_guard_release@plt> 0000000000400c2e callq 00000000004008ec = <__cxa_end_catch@plt> 0000000000400c33 xor %eax,%eax 0000000000400c35 add $0x8,%rsp 0000000000400c39 pop %rbx 0000000000400c3a pop %rbp 0000000000400c3b retq =20 The source for both is: #include #include void g(void) { throw std::exception(); } void f(void) { void *p =3D alloca(random() & 0xffu); g(); } int main(void) { void *p =3D alloca(random() & 0xffu); try { void *p2 =3D alloca(random() & 0xffu); f(); } catch (std::exception& e) { static void * volatile eaddr =3D &e; } return 0; } I've looked at 9.3-RELEASE as well. . . 9.3 does not compare against %edx but against %rdx. That is a 32-bit vs. 64-bit difference that would require a large value in %rdx to matter. I've not analyzed the libgcc_s.so.1 code for the "high bits" issue: are they always zero in each context that does a comparison? 9.3 has a _Unwind_Resume call based on the test. head and 9.3 compare against 0x1. The result is more similarity to head -r309179 than to stable/11 -r309125 in the program code (i.e., outside libgcc_s.so.1). [The libgcc_s.so.1 code is another matter.] (-O2 does not remove as much unnecessary code when gcc 4.2.1 is in use as well.) 9.3's code: 0000000000400ae0
push %rbp 0000000000400ae1 mov %rsp,%rbp 0000000000400ae4 push %rbx 0000000000400ae5 sub $0x8,%rsp 0000000000400ae9 callq 00000000004008bc 0000000000400aee and $0xff,%eax 0000000000400af3 add $0x1e,%rax 0000000000400af7 and $0x1f0,%eax 0000000000400afc sub %rax,%rsp 0000000000400aff callq 00000000004008bc 0000000000400b04 and $0xff,%eax 0000000000400b09 add $0x1e,%rax 0000000000400b0d and $0x1f0,%eax 0000000000400b12 sub %rax,%rsp 0000000000400b15 callq 0000000000400ab0 <_Z1fv> 0000000000400b1a mov -0x8(%rbp),%rbx 0000000000400b1e leaveq=20 0000000000400b1f xor %eax,%eax 0000000000400b21 retq =20 0000000000400b22 sub $0x1,%rdx 0000000000400b26 mov %rax,%rdi 0000000000400b29 je 0000000000400b30 0000000000400b2b callq 000000000040092c = <_Unwind_Resume@plt> 0000000000400b30 callq 00000000004008fc = <__cxa_begin_catch@plt> 0000000000400b35 cmpb $0x0,0x20046c(%rip) # = 0000000000600fa8 <_ZGVZ4mainE5eaddr> 0000000000400b3c mov %rax,%rbx 0000000000400b3f je 0000000000400b48 0000000000400b41 callq 00000000004008ec = <__cxa_end_catch@plt> 0000000000400b46 jmp 0000000000400b1a 0000000000400b48 mov $0x600fa8,%edi 0000000000400b4d callq 000000000040087c = <__cxa_guard_acquire@plt> 0000000000400b52 test %eax,%eax 0000000000400b54 je 0000000000400b41 0000000000400b56 mov $0x600fa8,%edi 0000000000400b5b mov %rbx,0x20044e(%rip) # = 0000000000600fb0 <_ZZ4mainE5eaddr> 0000000000400b62 callq 00000000004008ac = <__cxa_guard_release@plt> 0000000000400b67 jmp 0000000000400b41 So overall: A) stable/11 is the odd ball for code using libgcc_s.so.1 for exception handling B) head is the odd ball for the exception handling code in libgcc_s.so.1 Either way the compatibility looks problematical for spanning from 9.3 through head. Have you tried old 9.3, 10.x, or 11.x amd64 code that depends on C++ exceptions heavily on the more modern versions in each case? For example devel/kyua makes heavy use of C++ exceptions as I remember. (But I do not know how other aspects of compatibility would go for using old ones on newer systems.) I do not know how much kyua covers the variety of possible dependencies on the libgcc_s.so.1 C++ exception handling interface that a program could validly have. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-30, at 9:50 PM, Mark Millard wrote: [I add the dwarfdump -v -v -F /lib/libgcc_s.so.1 from 9.3-RELEASE -r268512 that does not agree with stable/11 -r309179's clang 3.9.0 content: it is like OpenMandriva Lx for the scratch register handling. I looked back this far because it was gcc 4.2.1 based for official amd64 releases.] On 2016-Nov-30, at 6:03 PM, Mark Millard wrote: > On 2016-Nov-29, at 2:56 PM, Ed Maste wrote: >=20 >> On 29 November 2016 at 16:46, Mark Millard = wrote: >>>=20 >>>=20 >>> Summary: Does using clang 3.9.0 as the system compiler imply one = should or >>> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions = work? >>>=20 >>> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same = criteria >>> for what dwarfdump should show for the exception information (if the >>> information to be shown is to be correct/sufficient for libunwind)? >>=20 >> It does not. It should be possible to build a functional system both >> WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the >> _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind >> data. >=20 > Good to know. Thanks. >=20 > [As there are no clang-based powerpc64 linux builds to my knowledge > the following uses amd64/x86_64 examples instead for comparisons.] >=20 > What I see from "dwarfdump -v -v -F .../libgcc_s.so.1" for FreeBSD > head -r309179 vs. what I see for the clang 3.8.0 based OpenMandriva > Lx V3.0 leaves me a little worried: OpenMandriva Lx V3.0 is more > like what I would expect for: >=20 > _Unwind_RaiseException (9990 vs. c701) > _Unwind_ForcedUnwind (a330 vs. c857) > _Unwind_Resume (9fb0 vs. c927) > _Unwind_Resume_or_Rethrow (2da0 vs. c9e4) >=20 > (The numbers are just for my reference in finding the dwarfdump > material.) >=20 > By contrast FreeBSD has missing information from what I can tell. >=20 > For these 4 routines only: OpenMandriva Lx has scratch registers > listed (r0 and r1 from the set of normally volatile registers > normally not listed). No other routines in libgcc_s.so.1 have > this. FreeBSD has no such extra registers listed anywhere, > including not on the 4 where I'd expect them. >=20 > Using _Unwind_RaiseException as an example of those 4 routines > that I'm worried about. . . >=20 > [Notes: r7 is %rsp, r6 is %rbp, r3 is %rbx, r2 is %rcx, r1 is %rdx, > and r0 is %rax in amd64/x86_64 land. Only OpenMandriva Lx had > examples of the last two. I use the dwarfdump naming below.] >=20 > FreeBSD _Unwind_RaiseException: >=20 > fde section offset 5328 0x000014d0 cie offset for fde: 5332 0x000014d4 > 0 DW_CFA_advance_loc 1 (1 * 1) > 1 DW_CFA_def_cfa_offset 16 > 3 DW_CFA_offset r6 -16 (2 * -8) > 5 DW_CFA_advance_loc 3 (3 * 1) > 6 DW_CFA_def_cfa_register r6 > 8 DW_CFA_advance_loc 16 (16 * 1) > 9 DW_CFA_offset r3 -56 (7 * -8) > 11 DW_CFA_offset r12 -48 (6 * -8) > 13 DW_CFA_offset r13 -40 (5 * -8) > 15 DW_CFA_offset r14 -32 (4 * -8) > 17 DW_CFA_offset r15 -24 (3 * -8) > 19 DW_CFA_nop > 20 DW_CFA_nop > 21 DW_CFA_nop > 22 DW_CFA_nop [It may be that some sort of update after 9.x makes what I report below expected. If so I've not identified it yet. At this point that is my guess: a different amd64 ABI now than in 9.3 for C++ exception handling, at least for some details.] The amd64 9.3-RELEASE -r268512 dwarfdump output for its _Unwind_RaiseException in its /lib/libgcc_s.so.1 does not match the above from stable/11 -r309179 for the scratch register handling. Note the r0 and r1 items (20 and 22): fde section offset 2672 0x00000a70 cie offset for fde: 2676 0x00000a74 0 DW_CFA_advance_loc 1 (1 * 1) 1 DW_CFA_def_cfa_offset 16 3 DW_CFA_offset r6 -16 (2 * -8) 5 DW_CFA_advance_loc 3 (3 * 1) 6 DW_CFA_def_cfa_register r6 8 DW_CFA_advance_loc 13 (13 * 1) 9 DW_CFA_offset r3 -56 (7 * -8) 11 DW_CFA_offset r12 -48 (6 * -8) 13 DW_CFA_offset r13 -40 (5 * -8) 15 DW_CFA_offset r14 -32 (4 * -8) 17 DW_CFA_offset r15 -24 (3 * -8) 19 DW_CFA_advance_loc 9 (9 * 1) 20 DW_CFA_offset r0 -72 (9 * -8) 22 DW_CFA_offset r1 -64 (8 * -8) 24 DW_CFA_nop 25 DW_CFA_nop 26 DW_CFA_nop 27 DW_CFA_nop 28 DW_CFA_nop 29 DW_CFA_nop 30 DW_CFA_nop The 9.3 code has %rdx (r2) and %rax (r0) saved and restored: 00000000000088d0 <_Unwind_RaiseException> push %rbp 00000000000088d1 <_Unwind_RaiseException+0x1> mov %rsp,%rbp 00000000000088d4 <_Unwind_RaiseException+0x4> push %r15 00000000000088d6 <_Unwind_RaiseException+0x6> lea 0x10(%rbp),%rsi 00000000000088da <_Unwind_RaiseException+0xa> push %r14 00000000000088dc <_Unwind_RaiseException+0xc> push %r13 00000000000088de <_Unwind_RaiseException+0xe> push %r12 00000000000088e0 <_Unwind_RaiseException+0x10> push %rbx 00000000000088e1 <_Unwind_RaiseException+0x11> lea -0x3a0(%rbp),%rbx 00000000000088e8 <_Unwind_RaiseException+0x18> push %rdx 00000000000088e9 <_Unwind_RaiseException+0x19> push %rax . . . (the code here freely assigns to and uses %rdx and %rax) . . . . . . (also there are multiple return paths with differing properties) . = . . 00000000000089a3 <_Unwind_RaiseException+0xd3> mov -0x28(%rbp),%rbx 00000000000089a7 <_Unwind_RaiseException+0xd7> mov -0x20(%rbp),%r12 00000000000089ab <_Unwind_RaiseException+0xdb> mov -0x18(%rbp),%r13 00000000000089af <_Unwind_RaiseException+0xdf> mov -0x10(%rbp),%r14 00000000000089b3 <_Unwind_RaiseException+0xe3> mov -0x8(%rbp),%r15 00000000000089b7 <_Unwind_RaiseException+0xe7> leaveq=20 00000000000089b8 <_Unwind_RaiseException+0xe8> retq =20 . . . (Note the lack of restoring %rax above and the normal %rbp/%rsp restore: leaveq) . . . . . . (before the below involves _Unwind_Backtrace that the above did not) . . . 0000000000008a33 <_Unwind_RaiseException+0x163> lea = 0x8(%rbp,%rcx,1),%rcx 0000000000008a38 <_Unwind_RaiseException+0x168> mov -0x38(%rbp),%rax 0000000000008a3c <_Unwind_RaiseException+0x16c> mov -0x30(%rbp),%rdx 0000000000008a40 <_Unwind_RaiseException+0x170> mov -0x28(%rbp),%rbx 0000000000008a44 <_Unwind_RaiseException+0x174> mov -0x20(%rbp),%r12 0000000000008a48 <_Unwind_RaiseException+0x178> mov -0x18(%rbp),%r13 0000000000008a4c <_Unwind_RaiseException+0x17c> mov -0x10(%rbp),%r14 0000000000008a50 <_Unwind_RaiseException+0x180> mov -0x8(%rbp),%r15 0000000000008a54 <_Unwind_RaiseException+0x184> mov 0x0(%rbp),%rbp 0000000000008a58 <_Unwind_RaiseException+0x188> mov %rcx,%rsp 0000000000008a5b <_Unwind_RaiseException+0x18b> retq . . . (Note the abnormal %rbp/%rsp restore above) . . . No other routine in 9.3's /lib/libgcc_s.so.1 pushes or pops either of %rdx or %rax: only _Unwind_RaiseException. The code structure allows executing exception landing-pad code and such during the exception handling with the 2 registers used to provide context. The stable/11 -r309179 code for _Unwind_RaiseException does not have those scratch registers saved and restored and has some other basic differences for related aspects: 0000000000009990 <_Unwind_RaiseException> push %rbp 0000000000009991 <_Unwind_RaiseException+0x1> mov %rsp,%rbp 0000000000009994 <_Unwind_RaiseException+0x4> push %r15 0000000000009996 <_Unwind_RaiseException+0x6> push %r14 0000000000009998 <_Unwind_RaiseException+0x8> push %r13 000000000000999a <_Unwind_RaiseException+0xa> push %r12 000000000000999c <_Unwind_RaiseException+0xc> push %rbx 000000000000999d <_Unwind_RaiseException+0xd> sub $0x418,%rsp . . . (the code here freely assigns to and uses %rdx and %rax) . . . 0000000000009c61 <_Unwind_RaiseException+0x2d1> add $0x418,%rsp 0000000000009c68 <_Unwind_RaiseException+0x2d8> pop %rbx 0000000000009c69 <_Unwind_RaiseException+0x2d9> pop %r12 0000000000009c6b <_Unwind_RaiseException+0x2db> pop %r13 0000000000009c6d <_Unwind_RaiseException+0x2dd> pop %r14 0000000000009c6f <_Unwind_RaiseException+0x2df> pop %r15 0000000000009c71 <_Unwind_RaiseException+0x2e1> pop %rbp 0000000000009c72 <_Unwind_RaiseException+0x2e2> retq No code in the stable/11 libgcc_s.so.1 has a "push %rdx", but lots of code there has a "push %rax". The only means by which _Unwind_RaiseException's %rsp is restored/"popped" is also very different for stable/11's code compared to the 2nd of the 9.3 code paths for returning: stable/11 seems to not have any match analogous to that path. The differences seem too large to be the same ABI when things seem to be working. (Although I've not tried 9.3 application code that uses C++ exceptions under stable/11 : old stuff could fail if well tested for all I know.) I've not looked at amd64 10.x yet. > All the registers referenced are very common: lots of routines > having nothing to do with the Exception handling also list them. >=20 > OpenMandriva Lx _Unwind_RaiseException: >=20 > fde section offset 4280 0x000010b8 cie offset for fde: 4284 0x000010bc > 0 DW_CFA_advance_loc 1 (1 * 1) > 1 DW_CFA_def_cfa_offset 16 > 3 DW_CFA_offset r6 -16 (2 * -8) > 5 DW_CFA_advance_loc 3 (3 * 1) > 6 DW_CFA_def_cfa_register r6 > 8 DW_CFA_advance_loc 8 (8 * 1) > 9 DW_CFA_offset r15 -24 (3 * -8) > 11 DW_CFA_offset r14 -32 (4 * -8) > 13 DW_CFA_offset r13 -40 (5 * -8) > 15 DW_CFA_offset r12 -48 (6 * -8) > 17 DW_CFA_advance_loc 20 (20 * 1) > 18 DW_CFA_offset r3 -56 (7 * -8) > 20 DW_CFA_offset r1 -64 (8 * -8) > 22 DW_CFA_offset r0 -72 (9 * -8) > 24 DW_CFA_advance_loc2 284 > 27 DW_CFA_remember_state > 28 DW_CFA_restore r6 > 29 DW_CFA_def_cfa r2 8 > 32 DW_CFA_advance_loc 4 (4 * 1) > 33 DW_CFA_restore_state > 34 DW_CFA_advance_loc 21 (21 * 1) > 35 DW_CFA_def_cfa r7 8 > 38 DW_CFA_nop >=20 > Note the lines for r1 and r0 that FreeBSD has no > equivalent of: These are the Exception ABI's > scratch registers usage that only apply to exception > handling code that uses certain built-ins that > imply the context. In normal routines r1 and r0 are > volatile and so are not listed on OpenMandriva Lx. >=20 > But FreeBSD never lists any scratch registers for the > exception handing ABI, unlike the Itanium's standard > that specified there are 4 --2 with predefined > purposes. (Itanimum used GP15-GP18 for the exception > handling scratch registers or something like that if > I remember right.) >=20 > So the amd64 FreeBSD information from clang 3.9.0 looks > wrong to me unless the Itanium's standard is not the > basis for what FreeBSD is doing here. >=20 > NOTE: Analogous incorrectness with observed scratch > register usage in builds based on clang 3.8.0 and > clang 3.9.0 for TARGET_ARCH=3Dpowerpc and > TARGET_ARCH=3Dpowerpc64 are part of what I've reported > as wrong to llvm for what blocks clang for them. In > this context actual crashes from asserts or SIGSEGV > during _Unwind_GetGR or _Unwind_SetGR for a scratch > register's index is what started my investigation of > the dwarfdump reports in the first place. I found > the register information missing in the dwarfdump > output and comments in the code about being such a > missing status for any GR leading to what I had > observed for references to that GR --and that is > my interpretation of the code so commented as well. >=20 >=20 >> Eventually new features may show up in Clang and LLVM's libunwind = (and >> new versions of GNU's unwinder) that won't work with the old = unwinder. >>=20 >>> Your answer's detail might indicate that I've misdirected the llvm = folks >>> in submittals like https://llvm.org/bugs/show_bug.cgi?id=3D26844 . >>>=20 >>> There is also the question of if/when llvm's libunwind is ready to = be used >>> for powerpc64 or powerpc (or . . .) if there are architecture = specifics >>> involved. That answer might determine when C++ exceptions work (and = so >>> when devel/kyua might have a chance to work) and is sort of separate = from >>> the main question here but is still of interest overall. >>>=20 >>> Should powerpc64 and powerpc clang 3.9.0 testing be using >>> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? >>=20 >> For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My >> eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, >> and ELF Tool Chain on all of our supported architectures. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Dec 2 04:57:38 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC9D5C6114C for ; Fri, 2 Dec 2016 04:57:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-58.reflexion.net [208.70.210.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 805E9160B for ; Fri, 2 Dec 2016 04:57:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31021 invoked from network); 2 Dec 2016 04:57:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Dec 2016 04:57:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 01 Dec 2016 23:57:43 -0500 (EST) Received: (qmail 10077 invoked from network); 2 Dec 2016 04:57:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Dec 2016 04:57:43 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 89CF0EC8FF8; Thu, 1 Dec 2016 20:57:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: Mark Millard In-Reply-To: <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> Date: Thu, 1 Dec 2016 20:57:34 -0800 Cc: FreeBSD Toolchain , Dimitry Andric , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 04:57:38 -0000 Quick summaries from looking around at official amd64 builds (via downloaded .iso's installed in VirtualBox under Mac OS X): _Unwind_RaiseException content (amd64 context only): RaiseExc. RaiseExc. RaiseException dwarfdump save/rest. has "mov %rcx,%rsp" r0?,r1? rdx? rax? return path? --------- ---------- ------------------ release/9.3.0: r0,r1 rdx,rax mov %rcx,%rsp path release/10.3.0: r0,r1 rdx,rax mov %rcx,%rsp path stable/10 -r309258: r0,r1 rdx,rax mov %rcx,%rsp path release/11.0.1: r0,r1 rdx,rax mov %rcx,%rsp path stable/11 -r309280: r0,r1 rdx,rax mov %rcx,%rsp path head (12) -r309302: My simple example program's content compiled under the host compiler: ("clang++ -g -std=3Dc++11 -pedantic -O2" when possible.) program uses pre _cxa_begin_catch compare and = jump _Unwind_Resume? logic? --------------- = ------------------------------------------- release/9.3.0: _Unwind_Resume sub $0x1,%rdx; je to = _cxa_begin_catch call release/10.3.0: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch stable/10 -r309258: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch release/11.0.1: stable/11 -r309280: head (12) -r309302: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-1, at 2:39 AM, Mark Millard wrote: > [A top-post noting that it is head -r309179 that is different > from 9.3-RELELASE for _Unwind_raiseException --and from > stable/11 -r309125-- after noting my repeated "stable/11" > references that should have said "head". Also for code > that uses libgcc_s.so.1 for C++ exception handling the > odd one is instead stable/11 that is not like the other > two.] >=20 > First a correction to a systematic typing error: >=20 > -r309179 was correct but it is head, not stable/11 . >=20 > I repeat: My earlier comparison was between amd64 > 9.3-RELEASE and amd64 12-CURRENT -r309179 . >=20 >=20 > What of stable/11 (by default WITHOUT_LLVM_LIBUNWIND=3D ) > vs. head (by default WITH_LLVM_LIBUNWIND=3D ) --and both > of those vs. release/9.3.0 (implicitly > WITHOUT_LLVM_LIBUNWIND=3D )? >=20 > First _Unwind_RaiseException as an example from > inside libgc_s.so.1 for exception handling. . . >=20 > head -r309179 does *not* match stable/11 -r309125 or > release/9.3.0 . >=20 > stable/11 -r309125 is more like release/9.3.0 . >=20 > So head *has* changed the amd64 C++ exception handling > details as far as I can tell: WITH_LLVM_LIBUNWIND > changes things. >=20 > A quick report below for stable/11 -r309125 shows > it has both styles of returns, like release/9.3.0 > does. It has r0 and r1 saved and restored too. >=20 > stable/11 -r309125 _Unwind_RaiseException's code has: >=20 > 0000000000002cb0 <_Unwind_RaiseException> push %rbp > 0000000000002cb1 <_Unwind_RaiseException+0x1> mov %rsp,%rbp > 0000000000002cb4 <_Unwind_RaiseException+0x4> push %r15 > 0000000000002cb6 <_Unwind_RaiseException+0x6> push %r14 > 0000000000002cb8 <_Unwind_RaiseException+0x8> push %r13 > 0000000000002cba <_Unwind_RaiseException+0xa> push %r12 > 0000000000002cbc <_Unwind_RaiseException+0xc> push %rbx > 0000000000002cbd <_Unwind_RaiseException+0xd> push %rdx > 0000000000002cbe <_Unwind_RaiseException+0xe> push %rax > 0000000000002cbf <_Unwind_RaiseException+0xf> sub $0x368,%rsp > . . . > [ the below is mostly like the 2nd 9.3 return path ] > 0000000000002e2b <_Unwind_RaiseException+0x17b> lea = 0x8(%rbp,%rax,1),%rcx > 0000000000002e30 <_Unwind_RaiseException+0x180> add $0x368,%rsp > 0000000000002e37 <_Unwind_RaiseException+0x187> pop %rax > 0000000000002e38 <_Unwind_RaiseException+0x188> pop %rdx > 0000000000002e39 <_Unwind_RaiseException+0x189> pop %rbx > 0000000000002e3a <_Unwind_RaiseException+0x18a> pop %r12 > 0000000000002e3c <_Unwind_RaiseException+0x18c> pop %r13 > 0000000000002e3e <_Unwind_RaiseException+0x18e> pop %r14 > 0000000000002e40 <_Unwind_RaiseException+0x190> pop %r15 > 0000000000002e42 <_Unwind_RaiseException+0x192> pop %rbp > 0000000000002e43 <_Unwind_RaiseException+0x193> mov %rcx,%rsp > 0000000000002e46 <_Unwind_RaiseException+0x196> retq =20 > [ the above really does update %rsp twice during the return > sequence; the first of those updates is ineffective overall > and is from not having set optimization explicitly ] > [ the below is much like the first 9.3 return path ] > 0000000000002e4a <_Unwind_RaiseException+0x19a> add $0x368,%rsp > 0000000000002e51 <_Unwind_RaiseException+0x1a1> pop %rax > 0000000000002e52 <_Unwind_RaiseException+0x1a2> pop %rdx > 0000000000002e53 <_Unwind_RaiseException+0x1a3> pop %rbx > 0000000000002e54 <_Unwind_RaiseException+0x1a4> pop %r12 > 0000000000002e56 <_Unwind_RaiseException+0x1a6> pop %r13 > 0000000000002e58 <_Unwind_RaiseException+0x1a8> pop %r14 > 0000000000002e5a <_Unwind_RaiseException+0x1aa> pop %r15 > 0000000000002e5c <_Unwind_RaiseException+0x1ac> pop %rbp > 0000000000002e5d <_Unwind_RaiseException+0x1ad> retq =20 >=20 > [Because of code order differences the above shows somewhat > more than I did for 9.3 .] >=20 > stable/11 -r309125 _Unwind_RaiseException's dwarfdump shows: >=20 > fde section offset 720 0x000002d0 cie offset for fde: 724 0x000002d4 > 0 DW_CFA_advance_loc 1 (1 * 1) > 1 DW_CFA_def_cfa_offset 16 > 3 DW_CFA_offset r6 -16 (2 * -8) > 5 DW_CFA_advance_loc 3 (3 * 1) > 6 DW_CFA_def_cfa_register r6 > 8 DW_CFA_advance_loc 18 (18 * 1) > 9 DW_CFA_offset r0 -72 (9 * -8) > 11 DW_CFA_offset r1 -64 (8 * -8) > 13 DW_CFA_offset r3 -56 (7 * -8) > 15 DW_CFA_offset r12 -48 (6 * -8) > 17 DW_CFA_offset r13 -40 (5 * -8) > 19 DW_CFA_offset r14 -32 (4 * -8) > 21 DW_CFA_offset r15 -24 (3 * -8) >=20 > Note the r0 and r1 (and %rax and %rdx in the code) > so it is like release/9.3.0 in that respect. >=20 >=20 > (I've still not looked at 10.x and with 11 being as it > is I might not bother.) >=20 >=20 >=20 > What about programs that use libgcc_s.so.1 ? . . . >=20 > Looking at an example program shows a code interface > difference visible in that code. Look just before the > __cxa_begin_catch@plt call in head vs. stable/11: > head -r309179 has conditional code that stable/11 > -r309125 does not: >=20 > 0000000000400caf cmp $0x1,%edx > 0000000000400cb2 jne 0000000000400cf3 >=20 > (This has -O2 in use for both contexts.) >=20 > head -r309179 has that conditional code: >=20 > 0000000000400c90
push %rbp > 0000000000400c91 mov %rsp,%rbp > 0000000000400c94 push %rbx > 0000000000400c95 push %rax > 0000000000400c96 callq 000000000040093c > 0000000000400c9b callq 000000000040093c > 0000000000400ca0 callq 000000000040093c > 0000000000400ca5 callq 0000000000400c50 <_Z1gv> > 0000000000400caa jmp 0000000000400cac > 0000000000400cac mov %rax,%rdi > 0000000000400caf cmp $0x1,%edx > 0000000000400cb2 jne 0000000000400cf3 > 0000000000400cb4 callq 000000000040097c = <__cxa_begin_catch@plt> > 0000000000400cb9 mov %rax,%rbx > 0000000000400cbc mov 0x20062e(%rip),%al # = 00000000006012f0 <_ZGVZ4mainE5eaddr> > 0000000000400cc2 test %al,%al > 0000000000400cc4 jne 0000000000400ce5 > 0000000000400cc6 mov $0x6012f0,%edi > 0000000000400ccb callq 00000000004008fc = <__cxa_guard_acquire@plt> > 0000000000400cd0 test %eax,%eax > 0000000000400cd2 je 0000000000400ce5 > 0000000000400cd4 mov %rbx,0x20060d(%rip) # = 00000000006012e8 <_ZZ4mainE5eaddr> > 0000000000400cdb mov $0x6012f0,%edi > 0000000000400ce0 callq 000000000040092c = <__cxa_guard_release@plt> > 0000000000400ce5 callq 000000000040096c = <__cxa_end_catch@plt> > 0000000000400cea xor %eax,%eax > 0000000000400cec add $0x8,%rsp > 0000000000400cf0 pop %rbx > 0000000000400cf1 pop %rbp > 0000000000400cf2 retq =20 > 0000000000400cf3 callq 00000000004009ac = <_Unwind_Resume@plt> >=20 > The call to _Unwind_Resume@plt above is another difference: > stable/11 does not have that. >=20 >=20 > stable/11 -r309125 does not have either of those points: >=20 > 0000000000400be1 mov %rsp,%rbp > 0000000000400be4 push %rbx > 0000000000400be5 push %rax > 0000000000400be6 callq 00000000004008bc > 0000000000400beb callq 00000000004008bc > 0000000000400bf0 callq 00000000004008bc > 0000000000400bf5 callq 0000000000400ba0 <_Z1gv> > 0000000000400bfa mov %rax,%rdi > 0000000000400bfd callq 00000000004008fc = <__cxa_begin_catch@plt> > 0000000000400c02 mov %rax,%rbx > 0000000000400c05 mov 0x2006c5(%rip),%al # = 00000000006012d0 <_ZGVZ4mainE5eaddr> > 0000000000400c0b test %al,%al > 0000000000400c0d jne 0000000000400c2e > 0000000000400c0f mov $0x6012d0,%edi > 0000000000400c14 callq 000000000040087c = <__cxa_guard_acquire@plt> > 0000000000400c19 test %eax,%eax > 0000000000400c1b je 0000000000400c2e > 0000000000400c1d mov %rbx,0x2006a4(%rip) # = 00000000006012c8 <_ZZ4mainE5eaddr> > 0000000000400c24 mov $0x6012d0,%edi > 0000000000400c29 callq 00000000004008ac = <__cxa_guard_release@plt> > 0000000000400c2e callq 00000000004008ec = <__cxa_end_catch@plt> > 0000000000400c33 xor %eax,%eax > 0000000000400c35 add $0x8,%rsp > 0000000000400c39 pop %rbx > 0000000000400c3a pop %rbp > 0000000000400c3b retq =20 >=20 > The source for both is: >=20 > #include > #include >=20 > void g(void) > { > throw std::exception(); > } >=20 > void f(void) > { > void *p =3D alloca(random() & 0xffu); > g(); > } >=20 > int main(void) > { > void *p =3D alloca(random() & 0xffu); > try { > void *p2 =3D alloca(random() & 0xffu); > f(); > } > catch (std::exception& e) { > static void * volatile eaddr =3D &e; > } > return 0; > } >=20 > I've looked at 9.3-RELEASE as well. . . >=20 > 9.3 does not compare against %edx but against %rdx. > That is a 32-bit vs. 64-bit difference that would > require a large value in %rdx to matter. I've not > analyzed the libgcc_s.so.1 code for the "high bits" > issue: are they always zero in each context that > does a comparison? >=20 > 9.3 has a _Unwind_Resume call based on the test. >=20 > head and 9.3 compare against 0x1. >=20 > The result is more similarity to head -r309179 than > to stable/11 -r309125 in the program code (i.e., > outside libgcc_s.so.1). >=20 > [The libgcc_s.so.1 code is another matter.] >=20 > (-O2 does not remove as much unnecessary code > when gcc 4.2.1 is in use as well.) >=20 > 9.3's code: >=20 > 0000000000400ae0
push %rbp > 0000000000400ae1 mov %rsp,%rbp > 0000000000400ae4 push %rbx > 0000000000400ae5 sub $0x8,%rsp > 0000000000400ae9 callq 00000000004008bc > 0000000000400aee and $0xff,%eax > 0000000000400af3 add $0x1e,%rax > 0000000000400af7 and $0x1f0,%eax > 0000000000400afc sub %rax,%rsp > 0000000000400aff callq 00000000004008bc > 0000000000400b04 and $0xff,%eax > 0000000000400b09 add $0x1e,%rax > 0000000000400b0d and $0x1f0,%eax > 0000000000400b12 sub %rax,%rsp > 0000000000400b15 callq 0000000000400ab0 <_Z1fv> > 0000000000400b1a mov -0x8(%rbp),%rbx > 0000000000400b1e leaveq=20 > 0000000000400b1f xor %eax,%eax > 0000000000400b21 retq =20 > 0000000000400b22 sub $0x1,%rdx > 0000000000400b26 mov %rax,%rdi > 0000000000400b29 je 0000000000400b30 > 0000000000400b2b callq 000000000040092c = <_Unwind_Resume@plt> > 0000000000400b30 callq 00000000004008fc = <__cxa_begin_catch@plt> > 0000000000400b35 cmpb $0x0,0x20046c(%rip) # = 0000000000600fa8 <_ZGVZ4mainE5eaddr> > 0000000000400b3c mov %rax,%rbx > 0000000000400b3f je 0000000000400b48 > 0000000000400b41 callq 00000000004008ec = <__cxa_end_catch@plt> > 0000000000400b46 jmp 0000000000400b1a > 0000000000400b48 mov $0x600fa8,%edi > 0000000000400b4d callq 000000000040087c = <__cxa_guard_acquire@plt> > 0000000000400b52 test %eax,%eax > 0000000000400b54 je 0000000000400b41 > 0000000000400b56 mov $0x600fa8,%edi > 0000000000400b5b mov %rbx,0x20044e(%rip) # = 0000000000600fb0 <_ZZ4mainE5eaddr> > 0000000000400b62 callq 00000000004008ac = <__cxa_guard_release@plt> > 0000000000400b67 jmp 0000000000400b41 >=20 >=20 >=20 > So overall: >=20 > A) stable/11 is the odd ball for code using libgcc_s.so.1 > for exception handling >=20 > B) head is the odd ball for the exception handling code > in libgcc_s.so.1 >=20 > Either way the compatibility looks problematical for > spanning from 9.3 through head. >=20 >=20 > Have you tried old 9.3, 10.x, or 11.x amd64 code that > depends on C++ exceptions heavily on the more modern > versions in each case? For example devel/kyua makes > heavy use of C++ exceptions as I remember. (But I do > not know how other aspects of compatibility would go > for using old ones on newer systems.) I do not know > how much kyua covers the variety of possible > dependencies on the libgcc_s.so.1 C++ exception > handling interface that a program could validly > have. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-30, at 9:50 PM, Mark Millard = wrote: >=20 > [I add the dwarfdump -v -v -F /lib/libgcc_s.so.1 from 9.3-RELEASE > -r268512 that does not agree with stable/11 -r309179's clang 3.9.0 > content: it is like OpenMandriva Lx for the scratch register > handling. I looked back this far because it was gcc 4.2.1 based > for official amd64 releases.] >=20 > On 2016-Nov-30, at 6:03 PM, Mark Millard wrote: >=20 >> On 2016-Nov-29, at 2:56 PM, Ed Maste wrote: >>=20 >>> On 29 November 2016 at 16:46, Mark Millard = wrote: >>>>=20 >>>>=20 >>>> Summary: Does using clang 3.9.0 as the system compiler imply one = should or >>>> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions = work? >>>>=20 >>>> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same = criteria >>>> for what dwarfdump should show for the exception information (if = the >>>> information to be shown is to be correct/sufficient for libunwind)? >>>=20 >>> It does not. It should be possible to build a functional system both >>> WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the >>> _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind >>> data. >>=20 >> Good to know. Thanks. >>=20 >> [As there are no clang-based powerpc64 linux builds to my knowledge >> the following uses amd64/x86_64 examples instead for comparisons.] >>=20 >> What I see from "dwarfdump -v -v -F .../libgcc_s.so.1" for FreeBSD >> head -r309179 vs. what I see for the clang 3.8.0 based OpenMandriva >> Lx V3.0 leaves me a little worried: OpenMandriva Lx V3.0 is more >> like what I would expect for: >>=20 >> _Unwind_RaiseException (9990 vs. c701) >> _Unwind_ForcedUnwind (a330 vs. c857) >> _Unwind_Resume (9fb0 vs. c927) >> _Unwind_Resume_or_Rethrow (2da0 vs. c9e4) >>=20 >> (The numbers are just for my reference in finding the dwarfdump >> material.) >>=20 >> By contrast FreeBSD has missing information from what I can tell. >>=20 >> For these 4 routines only: OpenMandriva Lx has scratch registers >> listed (r0 and r1 from the set of normally volatile registers >> normally not listed). No other routines in libgcc_s.so.1 have >> this. FreeBSD has no such extra registers listed anywhere, >> including not on the 4 where I'd expect them. >>=20 >> Using _Unwind_RaiseException as an example of those 4 routines >> that I'm worried about. . . >>=20 >> [Notes: r7 is %rsp, r6 is %rbp, r3 is %rbx, r2 is %rcx, r1 is %rdx, >> and r0 is %rax in amd64/x86_64 land. Only OpenMandriva Lx had >> examples of the last two. I use the dwarfdump naming below.] >>=20 >> FreeBSD _Unwind_RaiseException: >>=20 >> fde section offset 5328 0x000014d0 cie offset for fde: 5332 = 0x000014d4 >> 0 DW_CFA_advance_loc 1 (1 * 1) >> 1 DW_CFA_def_cfa_offset 16 >> 3 DW_CFA_offset r6 -16 (2 * -8) >> 5 DW_CFA_advance_loc 3 (3 * 1) >> 6 DW_CFA_def_cfa_register r6 >> 8 DW_CFA_advance_loc 16 (16 * 1) >> 9 DW_CFA_offset r3 -56 (7 * -8) >> 11 DW_CFA_offset r12 -48 (6 * -8) >> 13 DW_CFA_offset r13 -40 (5 * -8) >> 15 DW_CFA_offset r14 -32 (4 * -8) >> 17 DW_CFA_offset r15 -24 (3 * -8) >> 19 DW_CFA_nop >> 20 DW_CFA_nop >> 21 DW_CFA_nop >> 22 DW_CFA_nop >=20 > [It may be that some sort of update after 9.x makes what > I report below expected. If so I've not identified it yet. > At this point that is my guess: a different amd64 ABI now > than in 9.3 for C++ exception handling, at least for some > details.] >=20 > The amd64 9.3-RELEASE -r268512 dwarfdump output for its > _Unwind_RaiseException in its /lib/libgcc_s.so.1 does > not match the above from stable/11 -r309179 for the > scratch register handling. Note the r0 and r1 items > (20 and 22): >=20 > fde section offset 2672 0x00000a70 cie offset for fde: 2676 0x00000a74 > 0 DW_CFA_advance_loc 1 (1 * 1) > 1 DW_CFA_def_cfa_offset 16 > 3 DW_CFA_offset r6 -16 (2 * -8) > 5 DW_CFA_advance_loc 3 (3 * 1) > 6 DW_CFA_def_cfa_register r6 > 8 DW_CFA_advance_loc 13 (13 * 1) > 9 DW_CFA_offset r3 -56 (7 * -8) > 11 DW_CFA_offset r12 -48 (6 * -8) > 13 DW_CFA_offset r13 -40 (5 * -8) > 15 DW_CFA_offset r14 -32 (4 * -8) > 17 DW_CFA_offset r15 -24 (3 * -8) > 19 DW_CFA_advance_loc 9 (9 * 1) > 20 DW_CFA_offset r0 -72 (9 * -8) > 22 DW_CFA_offset r1 -64 (8 * -8) > 24 DW_CFA_nop > 25 DW_CFA_nop > 26 DW_CFA_nop > 27 DW_CFA_nop > 28 DW_CFA_nop > 29 DW_CFA_nop > 30 DW_CFA_nop >=20 > The 9.3 code has %rdx (r2) and %rax (r0) saved and > restored: >=20 > 00000000000088d0 <_Unwind_RaiseException> push %rbp > 00000000000088d1 <_Unwind_RaiseException+0x1> mov %rsp,%rbp > 00000000000088d4 <_Unwind_RaiseException+0x4> push %r15 > 00000000000088d6 <_Unwind_RaiseException+0x6> lea 0x10(%rbp),%rsi > 00000000000088da <_Unwind_RaiseException+0xa> push %r14 > 00000000000088dc <_Unwind_RaiseException+0xc> push %r13 > 00000000000088de <_Unwind_RaiseException+0xe> push %r12 > 00000000000088e0 <_Unwind_RaiseException+0x10> push %rbx > 00000000000088e1 <_Unwind_RaiseException+0x11> lea = -0x3a0(%rbp),%rbx > 00000000000088e8 <_Unwind_RaiseException+0x18> push %rdx > 00000000000088e9 <_Unwind_RaiseException+0x19> push %rax > . . . (the code here freely assigns to and uses %rdx and %rax) . . . > . . . (also there are multiple return paths with differing properties) = . . . > 00000000000089a3 <_Unwind_RaiseException+0xd3> mov -0x28(%rbp),%rbx > 00000000000089a7 <_Unwind_RaiseException+0xd7> mov -0x20(%rbp),%r12 > 00000000000089ab <_Unwind_RaiseException+0xdb> mov -0x18(%rbp),%r13 > 00000000000089af <_Unwind_RaiseException+0xdf> mov -0x10(%rbp),%r14 > 00000000000089b3 <_Unwind_RaiseException+0xe3> mov -0x8(%rbp),%r15 > 00000000000089b7 <_Unwind_RaiseException+0xe7> leaveq=20 > 00000000000089b8 <_Unwind_RaiseException+0xe8> retq =20 > . . . (Note the lack of restoring %rax above and the > normal %rbp/%rsp restore: leaveq) . . . > . . . (before the below involves _Unwind_Backtrace > that the above did not) . . . > 0000000000008a33 <_Unwind_RaiseException+0x163> lea = 0x8(%rbp,%rcx,1),%rcx > 0000000000008a38 <_Unwind_RaiseException+0x168> mov = -0x38(%rbp),%rax > 0000000000008a3c <_Unwind_RaiseException+0x16c> mov = -0x30(%rbp),%rdx > 0000000000008a40 <_Unwind_RaiseException+0x170> mov = -0x28(%rbp),%rbx > 0000000000008a44 <_Unwind_RaiseException+0x174> mov = -0x20(%rbp),%r12 > 0000000000008a48 <_Unwind_RaiseException+0x178> mov = -0x18(%rbp),%r13 > 0000000000008a4c <_Unwind_RaiseException+0x17c> mov = -0x10(%rbp),%r14 > 0000000000008a50 <_Unwind_RaiseException+0x180> mov -0x8(%rbp),%r15 > 0000000000008a54 <_Unwind_RaiseException+0x184> mov 0x0(%rbp),%rbp > 0000000000008a58 <_Unwind_RaiseException+0x188> mov %rcx,%rsp > 0000000000008a5b <_Unwind_RaiseException+0x18b> retq > . . . (Note the abnormal %rbp/%rsp restore above) . . . >=20 > No other routine in 9.3's /lib/libgcc_s.so.1 pushes or pops > either of %rdx or %rax: only _Unwind_RaiseException. >=20 > The code structure allows executing exception landing-pad > code and such during the exception handling with the 2 > registers used to provide context. >=20 > The stable/11 -r309179 code for _Unwind_RaiseException > does not have those scratch registers saved and restored > and has some other basic differences for related aspects: >=20 > 0000000000009990 <_Unwind_RaiseException> push %rbp > 0000000000009991 <_Unwind_RaiseException+0x1> mov %rsp,%rbp > 0000000000009994 <_Unwind_RaiseException+0x4> push %r15 > 0000000000009996 <_Unwind_RaiseException+0x6> push %r14 > 0000000000009998 <_Unwind_RaiseException+0x8> push %r13 > 000000000000999a <_Unwind_RaiseException+0xa> push %r12 > 000000000000999c <_Unwind_RaiseException+0xc> push %rbx > 000000000000999d <_Unwind_RaiseException+0xd> sub $0x418,%rsp > . . . (the code here freely assigns to and uses %rdx and %rax) . . . > 0000000000009c61 <_Unwind_RaiseException+0x2d1> add $0x418,%rsp > 0000000000009c68 <_Unwind_RaiseException+0x2d8> pop %rbx > 0000000000009c69 <_Unwind_RaiseException+0x2d9> pop %r12 > 0000000000009c6b <_Unwind_RaiseException+0x2db> pop %r13 > 0000000000009c6d <_Unwind_RaiseException+0x2dd> pop %r14 > 0000000000009c6f <_Unwind_RaiseException+0x2df> pop %r15 > 0000000000009c71 <_Unwind_RaiseException+0x2e1> pop %rbp > 0000000000009c72 <_Unwind_RaiseException+0x2e2> retq >=20 > No code in the stable/11 libgcc_s.so.1 has a "push %rdx", > but lots of code there has a "push %rax". >=20 > The only means by which _Unwind_RaiseException's %rsp is > restored/"popped" is also very different for stable/11's > code compared to the 2nd of the 9.3 code paths for > returning: stable/11 seems to not have any match analogous > to that path. >=20 > The differences seem too large to be the same ABI when things > seem to be working. (Although I've not tried 9.3 application > code that uses C++ exceptions under stable/11 : old stuff > could fail if well tested for all I know.) >=20 > I've not looked at amd64 10.x yet. >=20 >> All the registers referenced are very common: lots of routines >> having nothing to do with the Exception handling also list them. >>=20 >> OpenMandriva Lx _Unwind_RaiseException: >>=20 >> fde section offset 4280 0x000010b8 cie offset for fde: 4284 = 0x000010bc >> 0 DW_CFA_advance_loc 1 (1 * 1) >> 1 DW_CFA_def_cfa_offset 16 >> 3 DW_CFA_offset r6 -16 (2 * -8) >> 5 DW_CFA_advance_loc 3 (3 * 1) >> 6 DW_CFA_def_cfa_register r6 >> 8 DW_CFA_advance_loc 8 (8 * 1) >> 9 DW_CFA_offset r15 -24 (3 * -8) >> 11 DW_CFA_offset r14 -32 (4 * -8) >> 13 DW_CFA_offset r13 -40 (5 * -8) >> 15 DW_CFA_offset r12 -48 (6 * -8) >> 17 DW_CFA_advance_loc 20 (20 * 1) >> 18 DW_CFA_offset r3 -56 (7 * -8) >> 20 DW_CFA_offset r1 -64 (8 * -8) >> 22 DW_CFA_offset r0 -72 (9 * -8) >> 24 DW_CFA_advance_loc2 284 >> 27 DW_CFA_remember_state >> 28 DW_CFA_restore r6 >> 29 DW_CFA_def_cfa r2 8 >> 32 DW_CFA_advance_loc 4 (4 * 1) >> 33 DW_CFA_restore_state >> 34 DW_CFA_advance_loc 21 (21 * 1) >> 35 DW_CFA_def_cfa r7 8 >> 38 DW_CFA_nop >>=20 >> Note the lines for r1 and r0 that FreeBSD has no >> equivalent of: These are the Exception ABI's >> scratch registers usage that only apply to exception >> handling code that uses certain built-ins that >> imply the context. In normal routines r1 and r0 are >> volatile and so are not listed on OpenMandriva Lx. >>=20 >> But FreeBSD never lists any scratch registers for the >> exception handing ABI, unlike the Itanium's standard >> that specified there are 4 --2 with predefined >> purposes. (Itanimum used GP15-GP18 for the exception >> handling scratch registers or something like that if >> I remember right.) >>=20 >> So the amd64 FreeBSD information from clang 3.9.0 looks >> wrong to me unless the Itanium's standard is not the >> basis for what FreeBSD is doing here. >>=20 >> NOTE: Analogous incorrectness with observed scratch >> register usage in builds based on clang 3.8.0 and >> clang 3.9.0 for TARGET_ARCH=3Dpowerpc and >> TARGET_ARCH=3Dpowerpc64 are part of what I've reported >> as wrong to llvm for what blocks clang for them. In >> this context actual crashes from asserts or SIGSEGV >> during _Unwind_GetGR or _Unwind_SetGR for a scratch >> register's index is what started my investigation of >> the dwarfdump reports in the first place. I found >> the register information missing in the dwarfdump >> output and comments in the code about being such a >> missing status for any GR leading to what I had >> observed for references to that GR --and that is >> my interpretation of the code so commented as well. >>=20 >>=20 >>> Eventually new features may show up in Clang and LLVM's libunwind = (and >>> new versions of GNU's unwinder) that won't work with the old = unwinder. >>>=20 >>>> Your answer's detail might indicate that I've misdirected the llvm = folks >>>> in submittals like https://llvm.org/bugs/show_bug.cgi?id=3D26844 . >>>>=20 >>>> There is also the question of if/when llvm's libunwind is ready to = be used >>>> for powerpc64 or powerpc (or . . .) if there are architecture = specifics >>>> involved. That answer might determine when C++ exceptions work (and = so >>>> when devel/kyua might have a chance to work) and is sort of = separate from >>>> the main question here but is still of interest overall. >>>>=20 >>>> Should powerpc64 and powerpc clang 3.9.0 testing be using >>>> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? >>>=20 >>> For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My >>> eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, >>> and ELF Tool Chain on all of our supported architectures. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Fri Dec 2 08:12:41 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A527C61DDE for ; Fri, 2 Dec 2016 08:12:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-55.reflexion.net [208.70.210.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06FEF1DC9 for ; Fri, 2 Dec 2016 08:12:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27904 invoked from network); 2 Dec 2016 08:13:19 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Dec 2016 08:13:19 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 02 Dec 2016 03:12:19 -0500 (EST) Received: (qmail 26996 invoked from network); 2 Dec 2016 08:12:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Dec 2016 08:12:19 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 58EB3EC8B60; Fri, 2 Dec 2016 00:12:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: Mark Millard In-Reply-To: Date: Fri, 2 Dec 2016 00:12:31 -0800 Cc: FreeBSD Toolchain , Dimitry Andric , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:12:41 -0000 [Reminder of my context: these amd64 efforts are really trying to make sure that I interpret powerpc family behavior correctly for C++ exception handling. Still it may be that there are other useful side-effects of my investigations.] On 2016-Dec-1, at 8:57 PM, Mark Millard wrote: > Quick summaries from looking around at official amd64 builds > (via downloaded .iso's installed in VirtualBox under Mac OS X): >=20 > _Unwind_RaiseException content (amd64 context only): >=20 > RaiseExc. RaiseExc. RaiseException > dwarfdump save/rest. has "mov %rcx,%rsp" > r0?,r1? rdx? rax? return path? > --------- ---------- ------------------ > release/9.3.0: r0,r1 rdx,rax mov %rcx,%rsp path > release/10.3.0: r0,r1 rdx,rax mov %rcx,%rsp path > stable/10 -r309258: r0,r1 rdx,rax mov %rcx,%rsp path > release/11.0.1: r0,r1 rdx,rax mov %rcx,%rsp path > stable/11 -r309280: r0,r1 rdx,rax mov %rcx,%rsp path > head (12) -r309302: The following notes are not about the above differences in head vs. the others. I've not figured a good way to investigate the implications of head (12)'s differences above. > My simple example program's content compiled under the > host compiler: > ("clang++ -g -std=3Dc++11 -pedantic -O2" when possible.) >=20 > program uses pre _cxa_begin_catch compare and = jump > _Unwind_Resume? logic? > --------------- = ------------------------------------------- > release/9.3.0: _Unwind_Resume sub $0x1,%rdx; je to = _cxa_begin_catch call > release/10.3.0: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch > stable/10 -r309258: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch > release/11.0.1: > stable/11 -r309280: > head (12) -r309302: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch I explored more simple programs and. . . It looks like clang as it is in 11 treats: catch (std::& e) { . . . } as the last (or only) catch for a try as "catch everything" even for -O0 in the machine code, no separate _Unwind_Resume call for "no match". 11 depends on the other .eh information and its interpretation to avoid mis-delivery to the clause sequence for such a try. [The powerpc family may be similar. I need to avoid misreporting such differences from the general prior history to llvm as clang compiler problems.] [Back to amd64 land. . .] The other versions/configurations of clang and the g++ 4.2.1 compiler include the test and jump code to skip catches in sequence (including the last one in the try's source) and have use of _Unwind_Resume when the sequence does not have a match. So under 11.x older code's test and jump code might be redundant but is still apparently correct. It may be that such code is also redundant for head (12). But it appears that 12's machine code would then also have such redundant code as well. If there is some case where such code is not redundant for head (12) then 11's machine code might have problems under head in such cases. I do not know that any such case exists. I separately remind of the %rdx (64 bit) vs.=20 %edx (32-bit) use in the test and jump code, 9.3.0 code being the odd code with %rdx in use that involves more bits. [Again: The above ignores the head (12) differences in libgcc_s.so.1 .eh dwarf information for _Unwind_RaiseException and the like and the library's noted machine code differences for _Unwind_RaiseException as well.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Dec 2 10:29:49 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C942C62B59; Fri, 2 Dec 2016 10:29:49 +0000 (UTC) (envelope-from dc552@hermes.cam.ac.uk) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by mx1.freebsd.org (Postfix) with ESMTP id E77E61BE5; Fri, 2 Dec 2016 10:29:48 +0000 (UTC) (envelope-from dc552@hermes.cam.ac.uk) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host81-157-247-183.range81-157.btcentralplus.com ([81.157.247.183]:54643 helo=[192.168.1.65]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:dc552) (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cCl6A-0007EN-Sj (Exim 4.86_36-e07b163) (return-path ); Fri, 02 Dec 2016 10:29:46 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: David Chisnall In-Reply-To: Date: Fri, 2 Dec 2016 10:29:46 +0000 Cc: Ed Maste , FreeBSD Toolchain , Dimitry Andric , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3124) Sender: "Dr D. Chisnall" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 10:29:49 -0000 On 2 Dec 2016, at 08:12, Mark Millard wrote: >=20 > [Reminder of my context: these amd64 efforts are really > trying to make sure that I interpret powerpc family behavior > correctly for C++ exception handling. Still it may be that > there are other useful side-effects of my investigations.] There are two complexities in the unwind implementation: the generic = unwinder and the language-specific unwinder (the personality function = and the associated data in the language-specific data area, along with = how it uses these). The C++ implementation is probably the most = complicated of all of these (Ada might be more complex, but let=E2=80=99s = not go there). The C unwinder, which just implements = __attribute__((cleanup)) is very simple in comparison and should give = you easier code to debug (though you=E2=80=99ll need something higher up = the stack that actually catches the exception, as the unwinder won=E2=80=99= t enter a cleanup unless the exception is caught). The Objective-C = implementation is somewhere in between the two in terms of complexity. David From owner-freebsd-ppc@freebsd.org Fri Dec 2 21:37:39 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB795C6387C for ; Fri, 2 Dec 2016 21:37:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E494634 for ; Fri, 2 Dec 2016 21:37:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17286 invoked from network); 2 Dec 2016 21:11:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Dec 2016 21:11:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 02 Dec 2016 16:11:05 -0500 (EST) Received: (qmail 416 invoked from network); 2 Dec 2016 21:11:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Dec 2016 21:11:05 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 78DAAEC8B60; Fri, 2 Dec 2016 13:10:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work? From: Mark Millard In-Reply-To: Date: Fri, 2 Dec 2016 13:10:56 -0800 Cc: FreeBSD Toolchain , Dimitry Andric , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1016640A-6065-47A6-BF8C-F9DC2A38127A@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> <81CBAB7A-B855-4673-B2E2-7862F441FDDA@dsl-only.net> <68972A8F-C8D4-4FF2-A933-ACCC79C15065@dsl-only.net> <8BA319C6-FAD1-445F-85C1-5086B5AA59A8@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:37:39 -0000 On 2016-Dec-2, at 12:12 AM, Mark Millard wrote: > [Reminder of my context: these amd64 efforts are really > trying to make sure that I interpret powerpc family behavior > correctly for C++ exception handling. Still it may be that > there are other useful side-effects of my investigations.] >=20 > On 2016-Dec-1, at 8:57 PM, Mark Millard = wrote: >=20 >> Quick summaries from looking around at official amd64 builds >> (via downloaded .iso's installed in VirtualBox under Mac OS X): >>=20 >> _Unwind_RaiseException content (amd64 context only): >>=20 >> RaiseExc. RaiseExc. RaiseException >> dwarfdump save/rest. has "mov %rcx,%rsp" >> r0?,r1? rdx? rax? return path? >> --------- ---------- ------------------ >> release/9.3.0: r0,r1 rdx,rax mov %rcx,%rsp path >> release/10.3.0: r0,r1 rdx,rax mov %rcx,%rsp path >> stable/10 -r309258: r0,r1 rdx,rax mov %rcx,%rsp path >> release/11.0.1: r0,r1 rdx,rax mov %rcx,%rsp path >> stable/11 -r309280: r0,r1 rdx,rax mov %rcx,%rsp path >> head (12) -r309302: I have confirmed that head being different above for amd64 is because of the default WITH_LLVM_LIBUNWIND=3D and when built using WITHOUT_LLVM_LIBUNWIND=3D head is like the others for the above types of information. I've added a note to my llvm report (26844) for powerpc64 and powerpc indicating that all the specific material tied to dwarf .eh information that I reported is for use of WITHOUT_LLVM_LIBUNWIND=3D (for ppc and ppc64: the default for both FreeBSD 11 and currently for head [12]). I noted that comparing to WITH_LLVM_LIBUNWIND=3D dwarf information was more complicated: one needs to know the expected differences but I did not go into details. > The following notes are not about the above differences > in head vs. the others. I've not figured a good way to > investigate the implications of head (12)'s differences > above. >=20 >> My simple example program's content compiled under the >> host compiler: >> ("clang++ -g -std=3Dc++11 -pedantic -O2" when possible.) >>=20 >> program uses pre _cxa_begin_catch compare and = jump >> _Unwind_Resume? logic? >> --------------- = ------------------------------------------- >> release/9.3.0: _Unwind_Resume sub $0x1,%rdx; je to = _cxa_begin_catch call >> release/10.3.0: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch >> stable/10 -r309258: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch >> release/11.0.1: >> stable/11 -r309280: >> head (12) -r309302: _Unwind_Resume cmp $0x1,%edx; jne skips = _cxa_begin_catch These compiles have no clue if the eventual system was built using WITHOUT_LLVM_LIBUNWIND=3D vs. WITH_LLVM_LIBUNWIND=3D and so will persist independently. > I explored more simple programs and. . . >=20 > It looks like clang as it is in 11 treats: >=20 > catch (std::& e) { . . . } >=20 > as the last (or only) catch for a try as "catch > everything" even for -O0 in the machine code, > no separate _Unwind_Resume call for "no match". >=20 > 11 depends on the other .eh information and its > interpretation to avoid mis-delivery to the > clause sequence for such a try. >=20 > [The powerpc family may be similar. I need to > avoid misreporting such differences from the > general prior history to llvm as clang compiler > problems.] >=20 > [Back to amd64 land. . .] > The other versions/configurations of clang and the > g++ 4.2.1 compiler include the test and jump code > to skip catches in sequence (including the last one > in the try's source) and have use of _Unwind_Resume > when the sequence does not have a match. >=20 > So under 11.x older code's test and jump code might > be redundant but is still apparently correct. >=20 > It may be that such code is also redundant for head > (12). But it appears that 12's machine code would > then also have such redundant code as well. >=20 > If there is some case where such code is not > redundant for head (12) then 11's machine code > might have problems under head in such cases. > I do not know that any such case exists. >=20 >=20 > I separately remind of the %rdx (64 bit) vs.=20 > %edx (32-bit) use in the test and jump code, > 9.3.0 code being the odd code with %rdx in use > that involves more bits. >=20 >=20 > [Again: The above ignores the head (12) > differences in libgcc_s.so.1 .eh dwarf > information for _Unwind_RaiseException and > the like and the library's noted machine > code differences for _Unwind_RaiseException > as well.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Dec 3 03:38:54 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BBDAC630BF for ; Sat, 3 Dec 2016 03:38:54 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB6EC11FB for ; Sat, 3 Dec 2016 03:38:53 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-oi0-x230.google.com with SMTP id v84so286740610oie.3 for ; Fri, 02 Dec 2016 19:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eu9VsKR39yHDor3NA0BIEWLf/cyMmlux4d0ACooSo+8=; b=DojDAE4uoOQy/AEcxp3OU4qynRsT8PWDJpHVT/JpREM/G8/OmB06yQ49LpQqYn1Uye y3CXdhu7bNYQXKsogHPxmF1Q63t2iTfFxvEXyjn+QkpV3naUQiCRq0/y0PV16/jcHl98 wzKijJOKbi/fqX7PxFsEeNyvAmznCAPz3c+oI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Eu9VsKR39yHDor3NA0BIEWLf/cyMmlux4d0ACooSo+8=; b=SqNzfvOJ1uPcg/GYiTHd5FRLE6kX/uhtKJpecks7656lUUqjNHrNgigGEAw3NsOWSl 2yJMUoYWj5IcYbj2yifl2GAYVVNbrCZ4o62bzIg427z8WC/SfzDRbRNb1IWjU3E0v1do NkSIIDkfFcKhwe2EYMCP5w+HCPuQO4ubvu873HBUwuAjgKh+9ZAFpUOKZ31jw9GgPM8U MtzHzFSJfzV8gBzTCH8GB+7PDFJagzSiRnfGU3sQgGzDyuSyXnbeVw9Ma8BCR/LQHpC3 jiWppY3lhtBykLFxWKlo73rVxH+2/7ierMbU8UG7JUCjGhc+cwDBBp5TQJa0Fa1ESZJ4 nYQQ== X-Gm-Message-State: AKaTC03Coirh5IeOS2e3w/kw7cOqHRzE1n/L6Wa5/1OFK4Gt6RNX8ndbQ9kU0XT6RzAFYSf9vaNxxUHt2tiX8A== X-Received: by 10.157.7.38 with SMTP id 35mr27608424ote.87.1480736332812; Fri, 02 Dec 2016 19:38:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.50.228 with HTTP; Fri, 2 Dec 2016 19:38:52 -0800 (PST) In-Reply-To: <0BC8D9FA-2822-41CA-8CAE-89DCF9C4918F@dsl-only.net> References: <0BC8D9FA-2822-41CA-8CAE-89DCF9C4918F@dsl-only.net> From: Kevin Bowling Date: Fri, 2 Dec 2016 20:38:52 -0700 Message-ID: Subject: Re: Cross built head -r309179 TARGET_ARCH=powerpc64 with clang 3.9.0/powerpc64-binutils based buildworld operates; but fails "self-hosted buildworld" for undefined references To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric , Justin Hibbits Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 03:38:54 -0000 Interesting, that is quite a lot of progress if it boots with a crossbuild. I wonder if editing /usr/src/contrib/llvm/lib/Support/Atomic.cpp so the GNU_ATOMICS path is taken will work around these errors until someone more knowledgeable can comment. On Mon, Nov 28, 2016 at 4:02 AM, Mark Millard wrote: > [The powerpc64 self-hosted buildworld failure is for undefined > references to llvm::sys::CompareAndSwap and > llvm::sys::MemoryFence. See later below.] > > > I cross built TARGET_ARCH=powerpc64 head -r309179 via . . . > (has workaround matching -r309201 and my PowerMac G5 booting hack) > > buildworld via clang 3.9.0 and it using powerpc64-binutils > buildkernel via powerpc-xtoolchain-gcc (and so powerpc64-binutils) > > and installed and booted the combination: > > > # uname -apKU > > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r309179M: Mon Nov > 28 01:23:26 PST 2016 markmi@FreeBSDx64:/usr/obj/ > powerpc64vtsc_xtoolchain_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG > powerpc powerpc64 1200017 1200017 > > > > # clang --version > > FreeBSD clang version 3.9.0 (tags/RELEASE_390/final 280324) (based on > LLVM 3.9.0) > > Target: powerpc64-unknown-freebsd12.0 > > Thread model: posix > > InstalledDir: /usr/bin > > > I then attempted a self-hosted buildworld but it failed with: > > > Building /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full > > --- clang-tblgen.full --- > > /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a(ManagedStatic.o): > In function `getManagedStaticMutex()': > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1c4): > undefined reference to `llvm::sys::CompareAndSwap(unsigned int volatile*, > unsigned int, unsigned int)' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1d8): > undefined reference to `llvm::sys::MemoryFence()' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x220): > undefined reference to `llvm::sys::MemoryFence()' > > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > > *** [clang-tblgen.full] Error code 1 > > > > make[3]: stopped in /usr/src/usr.bin/clang/clang-tblgen > > .ERROR_TARGET='clang-tblgen.full' > > .ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang_ > altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/src/ > usr.bin/clang/clang-tblgen/clang-tblgen.full.meta' > > .MAKE.LEVEL='3' > > MAKEFILE='' > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > > .CURDIR='/usr/src/usr.bin/clang/clang-tblgen' > > .MAKE='make' > > .OBJDIR='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen' > > .TARGETS='all' > > DESTDIR='' > > LD_LIBRARY_PATH='' > > MACHINE='powerpc' > > MACHINE_ARCH='powerpc64' > > MAKEOBJDIRPREFIX='/usr/obj/powerpc64vtsc_clang_ > altbinutils_world/powerpc.powerpc64/usr/src/tmp' > > MAKESYSPATH='/usr/src/share/mk' > > MAKE_VERSION='20160818' > > PATH='/usr/obj/powerpc64vtsc_clang_altbinutils_world/ > powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin:/usr/obj/ > powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_ > altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/ > bin:/sbin:/bin:/usr/sbin:/usr/bin' > > SRCTOP='/usr/src' > > OBJTOP='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src' > > .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys. > env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf. > powerpc64-clang_altbinutils-bootstrap.powerpc64-host /usr/src/share/mk/ > bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk > /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk > /usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/clang/clang-tblgen/Makefile > /usr/src/usr.bin/clang/llvm.prog.mk /usr/src/lib/clang/llvm.pre.mk > /usr/src/lib/clang/llvm.build.mk /usr/src/tools/build/mk/bsd.prog.mk > /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk > /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk > /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk > /usr/src/usr.bin/clang/clang-tblgen/../Makefile.inc > /usr/src/usr.bin/clang/clang-tblgen/../../Makefile.inc /usr/src/share/mk/ > bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd. > compiler.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src. > libnames.mk /usr/src/ > share/mk/src.opts.mk /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/ > bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk > /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk > /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk > /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk > /usr/src/tools/build/mk/Makefile.boot' > > .PATH='. /usr/src/usr.bin/clang/clang-tblgen > /usr/src/contrib/llvm/tools/clang/utils/TableGen' > > 1 error > > . . . > > > > > > # less /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/ > clang-tblgen.full.meta > > # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/ > clang-tblgen.full.meta > > CMD /usr/bin/clang++ -B /usr/local/powerpc64-freebsd/bin/ -O2 -pipe > -I/usr/obj/powerpc64vtsc_clang_altbinutils_world/ > powerpc.powerpc64/usr/src/tmp/usr/src/lib/clang/libllvm > -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\ > "powerpc64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\" > powerpc64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/ > powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp\" -g > -Qunused-arguments -I/usr/obj/powerpc64vtsc_clang_altbinutils_world/ > powerpc.powerpc64/usr/src/tmp/legacy/usr/include -std=c++11 > -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -static > -L/usr/obj/powerpc64vtsc_clang_altbinutils_world/ > powerpc.powerpc64/usr/src/tmp/legacy/usr/lib -o clang-tblgen.full > ClangASTNodesEmitter.o ClangAttrEmitter.o ClangCommentCommandInfoEmitter.o > ClangCommentHTMLNamedCharacterReferenceEmitter.o ClangCommentHTMLTagsEmit > ter.o ClangDiagnosticsEmitter.o ClangSACheckersEmitter.o NeonEmitter.o > TableGen.o /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a > -lncursesw -lpthread -legacy > > CWD /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen > > TARGET clang-tblgen.full > > -- command output -- > > /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc. > powerpc64/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a(ManagedStatic.o): > In function `getManagedStaticMutex()': > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1c4): > undefined reference to `llvm::sys::CompareAndSwap(unsigned int volatile*, > unsigned int, unsigned int)' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1d8): > undefined reference to `llvm::sys::MemoryFence()' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x220): > undefined reference to `llvm::sys::MemoryFence()' > > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > > *** Error code 1 > . . . > > > > > # svnlite info /usr/src/ | grep "Re[lpv]" > > Relative URL: ^/head > > Repository Root: https://svn0.us-west.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 309179 > > Last Changed Rev: 309179 > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@freebsd.org Sat Dec 3 05:26:26 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70DE0C643CE for ; Sat, 3 Dec 2016 05:26:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34AF71E26 for ; Sat, 3 Dec 2016 05:26:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22085 invoked from network); 3 Dec 2016 05:26:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Dec 2016 05:26:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 03 Dec 2016 00:26:35 -0500 (EST) Received: (qmail 18478 invoked from network); 3 Dec 2016 05:26:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Dec 2016 05:26:35 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 759A3EC9149; Fri, 2 Dec 2016 21:26:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Cross built head -r309179 TARGET_ARCH=powerpc64 with clang 3.9.0/powerpc64-binutils based buildworld operates; but fails "self-hosted buildworld" for undefined references From: Mark Millard In-Reply-To: Date: Fri, 2 Dec 2016 21:26:22 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <456C1CB0-F194-4C0A-A74E-9482549B2A13@dsl-only.net> References: <0BC8D9FA-2822-41CA-8CAE-89DCF9C4918F@dsl-only.net> To: Kevin Bowling , Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 05:26:26 -0000 On 2016-Dec-2, at 7:38 PM, Kevin Bowling = wrote: > Interesting, that is quite a lot of progress if it boots with a = crossbuild. I wonder if editing = /usr/src/contrib/llvm/lib/Support/Atomic.cpp so the GNU_ATOMICS path is = taken will work around these errors until someone more knowledgeable can = comment. This is only buildworld, not buildkernel. Roman Divacky privately sent a note: > On 2016-Dec-2, at 2:52 AM, Roman Divacky = wrote: >=20 > Can you try to add Atomic.cpp to lib/clang/libllvmminimal/Makefile ? I have a buildworld (WITHOUT_LIB32=3D )on the powerpc64 that just finished while editing this note. It is based on the following change: # svnlite diff /usr/src/lib/clang/libllvmminimal/Makefile Index: /usr/src/lib/clang/libllvmminimal/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/lib/clang/libllvmminimal/Makefile (revision 309179) +++ /usr/src/lib/clang/libllvmminimal/Makefile (working copy) @@ -7,6 +7,7 @@ =20 SRCDIR=3D lib SRCS+=3D Support/APInt.cpp +SRCS+=3D Support/Atomic.cpp SRCS+=3D Support/CommandLine.cpp SRCS+=3D Support/ConvertUTF.c SRCS+=3D Support/ConvertUTFWrapper.cpp (So those "X86..." names might not be what the names suggested to me.) I'll try installing and rebooting somewhat later. One known area is the need to use WITHOUT_LIB32=3D because it rejects assembler notation that is in use. (I wonder of those "X86" file names might be associated with this.) Another known area is needing to avoid things that depend on C++ exception handling (for any exceptions that actually occur). Even: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } fails (calls abort). The buildworld's that I've done are based on implicit WITHOUT_LLVM_LIBUNWIND so far. clang 3.9.0 builds of devel/kyua are not able to run usefully yet because of the extensive C++ exception usage. The assembler notation issue is also involved if one tries to buildkernel as I remember. I had to use src.conf material to force clang 3.9.0 to use devel/binutils (powerpc64) or devel/powerpc64-binutils (amd64, possibly an alternative on powerpc64 as well) instead of using=20 bootstrapped system utils. This involved making sure that -B would make internal util use in clang/clang++ also redirect. Based on other's reports of having to revert them I've got: -r416639 of devel/binutils -r407342 of devel/powerpc64-binutils -r413189 of devel/powerpc64-gcc (devel/binutils used on powerpc64, devel/powerpc64-binutils used on amd64, devel/powerpc64-gcc not used in this activity but I have it around, both on amd64 and on powerpc64.) These reverts avoid 4.27 vintage materials for them. I'm not sure of the powerpc vs. powerpc64 vs. both status for this and simply decided to avoid the issue for now, testing other aspects of things since the binutils vintage issue was known to others and already public. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material. . . On Mon, Nov 28, 2016 at 4:02 AM, Mark Millard = wrote: > [The powerpc64 self-hosted buildworld failure is for undefined > references to llvm::sys::CompareAndSwap and > llvm::sys::MemoryFence. See later below.] >=20 >=20 > I cross built TARGET_ARCH=3Dpowerpc64 head -r309179 via . . . > (has workaround matching -r309201 and my PowerMac G5 booting hack) >=20 > buildworld via clang 3.9.0 and it using powerpc64-binutils > buildkernel via powerpc-xtoolchain-gcc (and so powerpc64-binutils) >=20 > and installed and booted the combination: >=20 > > # uname -apKU > > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r309179M: Mon = Nov 28 01:23:26 PST 2016 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain_kernel/powerpc.powerpc= 64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200017 1200017 >=20 >=20 > > # clang --version > > FreeBSD clang version 3.9.0 (tags/RELEASE_390/final 280324) (based = on LLVM 3.9.0) > > Target: powerpc64-unknown-freebsd12.0 > > Thread model: posix > > InstalledDir: /usr/bin >=20 >=20 > I then attempted a self-hosted buildworld but it failed with: >=20 > > Building = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full > > --- clang-tblgen.full --- > > = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a(ManagedStatic.o): = In function `getManagedStaticMutex()': > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1c4): = undefined reference to `llvm::sys::CompareAndSwap(unsigned int = volatile*, unsigned int, unsigned int)' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1d8): = undefined reference to `llvm::sys::MemoryFence()' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x220): = undefined reference to `llvm::sys::MemoryFence()' > > clang++: error: linker command failed with exit code 1 (use -v to = see invocation) > > *** [clang-tblgen.full] Error code 1 > > > > make[3]: stopped in /usr/src/usr.bin/clang/clang-tblgen > > .ERROR_TARGET=3D'clang-tblgen.full' > > = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc= .powerpc64/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.ful= l.meta' > > .MAKE.LEVEL=3D'3' > > MAKEFILE=3D'' > > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' > > .CURDIR=3D'/usr/src/usr.bin/clang/clang-tblgen' > > .MAKE=3D'make' > > = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc6= 4/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen' > > .TARGETS=3D'all' > > DESTDIR=3D'' > > LD_LIBRARY_PATH=3D'' > > MACHINE=3D'powerpc' > > MACHINE_ARCH=3D'powerpc64' > > = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc= .powerpc64/usr/src/tmp' > > MAKESYSPATH=3D'/usr/src/share/mk' > > MAKE_VERSION=3D'20160818' > > = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/u= sr/src/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/= powerpc.powerpc64/usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_= altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/bin:/sbin:/bin:/usr= /sbin:/usr/bin' > > SRCTOP=3D'/usr/src' > > = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64= /usr/src/tmp/usr/src' > > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.powerpc64= -host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/usr.bin/clang/clang-tblgen/Makefile = /usr/src/usr.bin/clang/llvm.prog.mk /usr/src/lib/clang/llvm.pre.mk = /usr/src/lib/clang/llvm.build.mk /usr/src/tools/build/mk/bsd.prog.mk = /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk = /usr/src/usr.bin/clang/clang-tblgen/../Makefile.inc = /usr/src/usr.bin/clang/clang-tblgen/../../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/ > share/mk/src.opts.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk /usr/src/tools/build/mk/Makefile.boot' > > .PATH=3D'. /usr/src/usr.bin/clang/clang-tblgen = /usr/src/contrib/llvm/tools/clang/utils/TableGen' > > 1 error >=20 > . . . >=20 >=20 >=20 >=20 > > # less = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full.meta > > # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen/clang-tblgen.full.meta > > CMD /usr/bin/clang++ -B /usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /tmp/usr/src/lib/clang/libllvm -I/usr/src/lib/clang/include = -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD = -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd12.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64-unknown-freebsd12.0\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/powerpc64vtsc_clang_altbinutils_world/power= pc.powerpc64/usr/src/tmp\" -g -Qunused-arguments = -I/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /tmp/legacy/usr/include -std=3Dc++11 -fno-exceptions -fno-rtti = -stdlib=3Dlibc++ -Wno-c++11-extensions -static = -L/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src= /tmp/legacy/usr/lib -o clang-tblgen.full ClangASTNodesEmitter.o = ClangAttrEmitter.o ClangCommentCommandInfoEmitter.o = ClangCommentHTMLNamedCharacterReferenceEmitter.o = ClangCommentHTMLTagsEmit > ter.o ClangDiagnosticsEmitter.o ClangSACheckersEmitter.o = NeonEmitter.o TableGen.o = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a -lncursesw = -lpthread -legacy > > CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/usr.bin/clang/clang-tblgen > > TARGET clang-tblgen.full > > -- command output -- > > = /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/t= mp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a(ManagedStatic.o): = In function `getManagedStaticMutex()': > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1c4): = undefined reference to `llvm::sys::CompareAndSwap(unsigned int = volatile*, unsigned int, unsigned int)' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x1d8): = undefined reference to `llvm::sys::MemoryFence()' > > /usr/src/contrib/llvm/lib/Support/ManagedStatic.cpp:(.text+0x220): = undefined reference to `llvm::sys::MemoryFence()' > > clang++: error: linker command failed with exit code 1 (use -v to = see invocation) > > *** Error code 1 > . . . >=20 >=20 >=20 > > # svnlite info /usr/src/ | grep "Re[lpv]" > > Relative URL: ^/head > > Repository Root: https://svn0.us-west.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 309179 > > Last Changed Rev: 309179 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net