From owner-freebsd-toolchain@freebsd.org Sun Nov 27 00:02:34 2016 Return-Path: Delivered-To: freebsd-toolchain@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 69EECC57A03 for ; Sun, 27 Nov 2016 00:02:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 4068EFD0 for ; Sun, 27 Nov 2016 00:02:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAR02XAA006009 for ; Sun, 27 Nov 2016 00:02:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Sun, 27 Nov 2016 00:02:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc blocked flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 00:02:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Bug ID: 214863 Summary: lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Keywords: regression Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: gerald@FreeBSD.org Reporter: jbeich@FreeBSD.org CC: freebsd-toolchain@FreeBSD.org Blocks: 196712 Flags: maintainer-feedback?(gerald@FreeBSD.org) Assignee: gerald@FreeBSD.org Bug 196712 regressed USES=3Dcompiler:gcc-c++11-lib ports. gcc49 or later ap= pear to have the following regression on /releng/10.1. Maybe toolchain@ has a cl= ue. $ cat a.cc int main() { // Snippet from lilypond-devel int argc =3D 5; char **argv =3D new char*[argc + 2]; return 0; } $ pkg install -y gcc libc++ $ g++49 -std=3Dc++11 -nostdinc++ -isystem /usr/local/include/c++/v1 -L/usr/local/lib/c++ a.cc /tmp//ccZYfujU.o: In function `main': a.cc:(.text+0x2b): undefined reference to `__cxa_throw_bad_array_new_leng= th' collect2: error: ld returned 1 exit status Affected ports: cad/openvsp math/ceres-solver math/saga print/lilypond-devel Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196712 [Bug 196712] exp-run: Update lang/gcc from GCC 4.8 to GCC 4.9 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Nov 27 00:41:10 2016 Return-Path: Delivered-To: freebsd-toolchain@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 7C9A8C4B552 for ; Sun, 27 Nov 2016 00:41:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-32.reflexion.net [208.70.210.32]) (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 3AFFF85 for ; Sun, 27 Nov 2016 00:41:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17195 invoked from network); 27 Nov 2016 00:40:52 -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:40:52 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 00:41:10 -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-toolchain@freebsd.org Sun Nov 27 03:47:45 2016 Return-Path: Delivered-To: freebsd-toolchain@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 9D233C56EE6 for ; Sun, 27 Nov 2016 03:47:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-35.reflexion.net [208.70.210.35]) (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 6270FAEC for ; Sun, 27 Nov 2016 03:47:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26684 invoked from network); 27 Nov 2016 03:48:23 -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:48:23 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 03:47:45 -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-toolchain@freebsd.org Sun Nov 27 09:31:47 2016 Return-Path: Delivered-To: freebsd-toolchain@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 34DB5C5844A for ; Sun, 27 Nov 2016 09:31:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-34.reflexion.net [208.70.210.34]) (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 ED458BF7 for ; Sun, 27 Nov 2016 09:31:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22884 invoked from network); 27 Nov 2016 09:31:24 -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:24 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 09:31:47 -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-toolchain@freebsd.org Sun Nov 27 17:15:35 2016 Return-Path: Delivered-To: freebsd-toolchain@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 0B463C59092 for ; Sun, 27 Nov 2016 17:15:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 EE8AF7F6 for ; Sun, 27 Nov 2016 17:15:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uARHFYsf052751 for ; Sun, 27 Nov 2016 17:15:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Sun, 27 Nov 2016 17:15:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 17:15:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #1 from Dimitry Andric --- This is because g++ 4.9 is now inserting a call to __cxa_throw_bad_array_new_length, e.g.: main: .LFB0: .cfi_startproc leal 4(%esp), %ecx .cfi_def_cfa 1, 0 andl $-16, %esp pushl -4(%ecx) pushl %ebp .cfi_escape 0x10,0x5,0x2,0x75,0 movl %esp, %ebp pushl %ecx .cfi_escape 0xf,0x3,0x75,0x7c,0x6 subl $20, %esp movl $5, -12(%ebp) movl -12(%ebp), %eax addl $2, %eax cmpl $532676608, %eax ja .L2 sall $2, %eax jmp .L5 .L2: call __cxa_throw_bad_array_new_length but the support for this call was only merged to stable/10 in r278724, way after 10.1-R was created. One option is to compile the program without exception support, or to explicitly use gcc 4.8 or lower. I could not find a gcc command line optio= n to disable the generation of these calls. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Nov 27 21:08:01 2016 Return-Path: Delivered-To: freebsd-toolchain@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 0E67BC58724 for ; Sun, 27 Nov 2016 21:08:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 F10F315E0 for ; Sun, 27 Nov 2016 21:08:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uARL80Xj067879 for ; Sun, 27 Nov 2016 21:08:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214862] head -r309197 clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them Date: Sun, 27 Nov 2016 21:08:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 21:08:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214862 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Nov 27 21:10:48 2016 Return-Path: Delivered-To: freebsd-toolchain@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 92438C5894A for ; Sun, 27 Nov 2016 21:10:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 80B8F16EB for ; Sun, 27 Nov 2016 21:10:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uARLAmhD074681 for ; Sun, 27 Nov 2016 21:10:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error Date: Sun, 27 Nov 2016 21:10:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 21:10:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214855 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 00:34:09 2016 Return-Path: Delivered-To: freebsd-toolchain@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 2A766C59A84 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 BB01322AB for ; Mon, 28 Nov 2016 00:34:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26171 invoked from network); 28 Nov 2016 00:34:47 -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:34:47 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Nov 28 00:44:46 2016 Return-Path: Delivered-To: freebsd-toolchain@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 19BC3C59D93 for ; Mon, 28 Nov 2016 00:44:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 0861E294A for ; Mon, 28 Nov 2016 00:44:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAS0ii4i078179 for ; Mon, 28 Nov 2016 00:44:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Mon, 28 Nov 2016 00:44:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc flagtypes.name attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 00:44:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |portmgr@FreeBSD.org Attachment #177468| |maintainer-approval?(portmg Flags| |r@FreeBSD.org) --- Comment #2 from Jan Beich (mail not working) --- Created attachment 177468 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177468&action= =3Dedit gcc48 workaround Maybe dangerous if USES=3Dcompiler:gcc-c++11-lib is mixed with USES=3Dfortr= an in dependencies. I've only tested direct consumers. graphics/GraphicsMagick ha= d to be patched to avoid breaking science/gnudatalanguage: http://sprunge.us/bMYN --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 03:01:41 2016 Return-Path: Delivered-To: freebsd-toolchain@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 6D1BEC586E8 for ; Mon, 28 Nov 2016 03:01:41 +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 326833F4 for ; Mon, 28 Nov 2016 03:01:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22375 invoked from network); 28 Nov 2016 03:02:14 -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:02:14 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 03:01:41 -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-toolchain@freebsd.org Mon Nov 28 03:10:43 2016 Return-Path: Delivered-To: freebsd-toolchain@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 B8EF5C589BC for ; Mon, 28 Nov 2016 03:10:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 6C999A04 for ; Mon, 28 Nov 2016 03:10:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24321 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 03:10:43 -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-toolchain@freebsd.org Mon Nov 28 08:37:24 2016 Return-Path: Delivered-To: freebsd-toolchain@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 57A48C57B83 for ; Mon, 28 Nov 2016 08:37:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 462981634 for ; Mon, 28 Nov 2016 08:37:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAS8bNWQ095081 for ; Mon, 28 Nov 2016 08:37:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Mon, 28 Nov 2016 08:37:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 08:37:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |theraven@FreeBSD.org --- Comment #3 from David Chisnall --- It would be good to put out an EN for the libcxxrt change and merge it back= to all supported branches - the same problem will occur if you are using a rec= ent clang on these systems. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 11:02:27 2016 Return-Path: Delivered-To: freebsd-toolchain@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 34CFDC594ED for ; Mon, 28 Nov 2016 11:02:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-35.reflexion.net [208.70.210.35]) (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 EE1A4135E for ; Mon, 28 Nov 2016 11:02:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9882 invoked from network); 28 Nov 2016 11:02:05 -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:05 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 11:02:27 -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-toolchain@freebsd.org Mon Nov 28 11:08:53 2016 Return-Path: Delivered-To: freebsd-toolchain@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 0C9B4C5973F for ; Mon, 28 Nov 2016 11:08:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 EF49315CC for ; Mon, 28 Nov 2016 11:08:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASB8qHi079145 for ; Mon, 28 Nov 2016 11:08:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214862] head -r309179 clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them Date: Mon, 28 Nov 2016 11:08:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 11:08:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214862 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|head -r309197 clang 3.9.0 |head -r309179 clang 3.9.0 |vs. TARGET_ARCH=3Dpowerpc: |vs. TARGET_ARCH=3Dpowerp= c: |fsck_ufs and "df -m" are |fsck_ufs and "df -m" are |example failures: |example failures: |__floatdidf gets SIGSEGV's |__floatdidf gets SIGSEGV's |in both of them |in both of them --- Comment #4 from Mark Millard --- I seem to have consistently typed -r309197 instead of the correct: -r309179 This was based on head -r309179 despite any earlier claims otherwise. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 11:52:19 2016 Return-Path: Delivered-To: freebsd-toolchain@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 3497EC5958D for ; Mon, 28 Nov 2016 11:52:19 +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 DD0271D0E for ; Mon, 28 Nov 2016 11:52:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23327 invoked from network); 28 Nov 2016 11:51:56 -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:51:56 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 11:52:19 -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-toolchain@freebsd.org Mon Nov 28 18:39:23 2016 Return-Path: Delivered-To: freebsd-toolchain@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 A7D5CC59A5B for ; Mon, 28 Nov 2016 18:39:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 96FB11CFA for ; Mon, 28 Nov 2016 18:39:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASIdNWn028574 for ; Mon, 28 Nov 2016 18:39:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 193594] stddef.h should define max_align_t Date: Mon, 28 Nov 2016 18:39:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: dep_changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:39:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193594 Bug 193594 depends on bug 210890, which changed state. Bug 210890 Summary: [exp-run] Define max_align_t for C11 and C++11 in stdde= f.h https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210890 What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 18:54:27 2016 Return-Path: Delivered-To: freebsd-toolchain@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 D77FEC59F52 for ; Mon, 28 Nov 2016 18:54:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 BC11B1628 for ; Mon, 28 Nov 2016 18:54:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASIsRZ7067941 for ; Mon, 28 Nov 2016 18:54:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Mon, 28 Nov 2016 18:54:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:54:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 --- Comment #4 from Dimitry Andric --- (In reply to David Chisnall from comment #3) > It would be good to put out an EN for the libcxxrt change and merge it ba= ck > to all supported branches - the same problem will occur if you are using a > recent clang on these systems. 10.1 and 10.2 have one month of life left... Do you really think this is wo= rth the trouble? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 19:15:57 2016 Return-Path: Delivered-To: freebsd-toolchain@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 249B9C5A43D for ; Mon, 28 Nov 2016 19:15:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 13B9A102F for ; Mon, 28 Nov 2016 19:15:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASJFu2h052000 for ; Mon, 28 Nov 2016 19:15:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation Date: Mon, 28 Nov 2016 19:15:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 19:15:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 19:16:09 2016 Return-Path: Delivered-To: freebsd-toolchain@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 38C77C5A489 for ; Mon, 28 Nov 2016 19:16:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 2741110BA for ; Mon, 28 Nov 2016 19:16:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASJG8Fx052346 for ; Mon, 28 Nov 2016 19:16:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214903] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross built buildkernel stops for: converts between pointers to integer types with different sign [-Werror,-Wpointer-sign] Date: Mon, 28 Nov 2016 19:16:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 19:16:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 19:16:25 2016 Return-Path: Delivered-To: freebsd-toolchain@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 A258AC5A4EB for ; Mon, 28 Nov 2016 19:16:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 914B31184 for ; Mon, 28 Nov 2016 19:16:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASJGPMA052679 for ; Mon, 28 Nov 2016 19:16:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Mon, 28 Nov 2016 19:16:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 19:16:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 20:30:34 2016 Return-Path: Delivered-To: freebsd-toolchain@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 6E323C58F22 for ; Mon, 28 Nov 2016 20:30:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 3E24415A1 for ; Mon, 28 Nov 2016 20:30:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASKUYul051844 for ; Mon, 28 Nov 2016 20:30:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Mon, 28 Nov 2016 20:30:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 20:30:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) The stage was: >>> stage 1.2: bootstrap tools During: --- _bootstrap-tools-usr.bin/clang/clang-tblgen --- and . . . --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- It looks like this llvm activity needs to compile and link in: llvm/lib/Support/Atomic.cpp which defines the two routines: #include "llvm/Support/Atomic.h" #include "llvm/Config/llvm-config.h" using namespace llvm; #if defined(_MSC_VER) #include #include #undef MemoryFence #endif #if defined(__GNUC__) || (defined(__IBMCPP__) && __IBMCPP__ >=3D 1210) #define GNU_ATOMICS #endif void sys::MemoryFence() { #if LLVM_HAS_ATOMICS =3D=3D 0 return; #else # if defined(GNU_ATOMICS) __sync_synchronize(); # elif defined(_MSC_VER) MemoryBarrier(); # else # error No memory fence implementation for your platform! # endif #endif } sys::cas_flag sys::CompareAndSwap(volatile sys::cas_flag* ptr, sys::cas_flag new_value, sys::cas_flag old_value) { #if LLVM_HAS_ATOMICS =3D=3D 0 sys::cas_flag result =3D *ptr; if (result =3D=3D old_value) *ptr =3D new_value; return result; #elif defined(GNU_ATOMICS) return __sync_val_compare_and_swap(ptr, old_value, new_value); #elif defined(_MSC_VER) return InterlockedCompareExchange(ptr, new_value, old_value); #else # error No compare-and-swap implementation for your platform! #endif } --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Nov 28 20:55:16 2016 Return-Path: Delivered-To: freebsd-toolchain@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 4904AC59780 for ; Mon, 28 Nov 2016 20:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 37E9D1564 for ; Mon, 28 Nov 2016 20:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uASKtGwQ010978 for ; Mon, 28 Nov 2016 20:55:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Mon, 28 Nov 2016 20:55:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 20:55:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 --- Comment #2 from Mark Millard --- Another question (besides not finding a reference to llvm's Atomic.cpp): Using llvm-tblgen as an example on a powerpc64 host: it looks like the Makefile(s) is(/are) for X86 specifically . . . # $FreeBSD: head/usr.bin/clang/llvm-tblgen/Makefile 309124 2016-11-24 22:54= :55Z dim $ PROG_CXX=3D llvm-tblgen SRCDIR=3D utils/TableGen . . . SRCS+=3D TableGen.cpp SRCS+=3D X86DisassemblerTables.cpp SRCS+=3D X86ModRMFilters.cpp SRCS+=3D X86RecognizableInstr.cpp .include "../llvm.prog.mk" There are no obvious powerpc64 references. Or may be I'm inferring too much from the structure of the names? Is the intent only tier 1 types of hosts? Only x86/amd64 variants even if some other type(s) of tier 1 host(s) exist? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Nov 29 00:28:02 2016 Return-Path: Delivered-To: freebsd-toolchain@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 5DB42C587BF for ; Tue, 29 Nov 2016 00:28:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 3F40C130B for ; Tue, 29 Nov 2016 00:28:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAT0S1ug079776 for ; Tue, 29 Nov 2016 00:28:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Tue, 29 Nov 2016 00:28:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 00:28:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org --- Comment #5 from Ed Maste --- > 10.1 and 10.2 have one month of life left... Do you really think this is = worth > the trouble? Regardless of the branches still being supported today, some of our downstr= eam consumers continue to use FreeBSD releases long after they're no longer supported. I think there is value in an EN even if the branch is EOL at the= end of the year. I can't really say for sure that this is enough value to justi= fy the effort: I suspect those downstream users don't follow -pN releases dire= ctly anyhow and it's easy enough for them to incorporate the patch into their lo= cal tree. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Nov 29 08:34:05 2016 Return-Path: Delivered-To: freebsd-toolchain@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 5A8F9C5C566 for ; Tue, 29 Nov 2016 08:34:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 4155619C7 for ; Tue, 29 Nov 2016 08:34:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAT8Y4I4095027 for ; Tue, 29 Nov 2016 08:34:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Tue, 29 Nov 2016 08:34:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mat@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 08:34:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 --- Comment #6 from Mathieu Arnold --- Up until a branch is out of support, it should get all the EN/SA that we promise. So any EN/SA that comes out before January 1st should include 10.1= and 10.2 (and 9.3 if applicable) Now, after the support runs out, we should really not support them any more, otherwise, people will start expecting our EOL to be automatically extended, and I am not sure secteam@ or re@ has the manpower to handle that. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Nov 29 09:22:09 2016 Return-Path: Delivered-To: freebsd-toolchain@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 595F7C5963F for ; Tue, 29 Nov 2016 09:22:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 41D50129C for ; Tue, 29 Nov 2016 09:22:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 41374C5963E; Tue, 29 Nov 2016 09:22:09 +0000 (UTC) Delivered-To: toolchain@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 40B6DC5963D; Tue, 29 Nov 2016 09:22:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6EE01290; Tue, 29 Nov 2016 09:22:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAT9M0qI009034 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Nov 2016 11:22:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAT9M0qI009034 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAT9M0DP009033; Tue, 29 Nov 2016 11:22:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Nov 2016 11:22:00 +0200 From: Konstantin Belousov To: Dewayne Geraghty Cc: freebsd-stable stable , toolchain@freebsd.org Subject: Re: How to turn off SSP stack-protector on 11.0S Message-ID: <20161129092200.GU54029@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 09:22:09 -0000 On Tue, Nov 29, 2016 at 12:32:28PM +1100, Dewayne Geraghty wrote: > Is WITHOUT_SSP actually honoured and is building a world and/or ports > without SSP possible? Advise/suggestions appreciated. > > Amongst the 9 different server configurations that we build/support, we've > been asked to build a machine dedicated to PROLOG use. (yes really). > > As such we're trying to turn off everything that isn't needed for this > particular server. For those concerned with security, it is an air-gap > machine receiving data via usb. > > We've built/installed 11.0S from source. Now we're building the custom > server. However, even with WITHOUT_SSP= in both /etc/make.conf and > /etc/src.conf, we come up against little issues like: > "can not find /usr/lib/libssp_nonshared.a" So, does your host have /usr/lib/libssp_nonshared.a ? How did you installed 11.0, and what does designator 11.0S above mean ? Easy way out is to claim that r307146 should help you, but I suspect that there is something more broken in your configuration or build/install method. > > An example: > Stage 2.3: build tools > ===> bin/csh (obj,build-tools) > grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' > >> sh.err.h > cc -E -O2 -pipe -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UDEBUG > -DUSB_HAVE_DISABLE_ENUM -I. -I/usr/src/bin/csh > -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -g > -std=gnu99 -Qunused-arguments > -I/usr/obj/prod/110001/D/K8/usr/src/tmp/legacy/usr/include > /usr/src/bin/csh/../../contrib/tcsh/tc.const.c > /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h > /usr/src/bin/csh/../../contrib/tcsh/config_f.h > /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | > grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char > \1[];/' | sort >> tc.const.h > cc -o gethost -L/usr/obj/prod/110001/D/K8/usr/src/tmp/legacy/usr/lib -O2 > -pipe -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UDEBUG > -DUSB_HAVE_DISABLE_ENUM -I. -I/usr/src/bin/csh > -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -g > -std=gnu99 -Qunused-arguments > -I/usr/obj/prod/110001/D/K8/usr/src/tmp/legacy/usr/include > /usr/src/bin/csh/../../contrib/tcsh/gethost.c > /usr/bin/ld: cannot find /usr/lib/libssp_nonshared.a > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [gethost] Error code 1 > > Note the > /usr/bin/ld: cannot find /usr/lib/libssp_nonshared.a > > It seems that the linker is trying to use the above library during the > build of all static images/executables. P.S. Toolchain@ is the place where you more likely to get a useful feedback. From owner-freebsd-toolchain@freebsd.org Tue Nov 29 21:53:43 2016 Return-Path: Delivered-To: freebsd-toolchain@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 20250C5C662 for ; Tue, 29 Nov 2016 21:53:43 +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 D96341EEB for ; Tue, 29 Nov 2016 21:53:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8777 invoked from network); 29 Nov 2016 21:46:48 -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:48 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 21:53:43 -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-toolchain@freebsd.org Tue Nov 29 22:57:08 2016 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Wed Nov 30 10:35:29 2016 Return-Path: Delivered-To: freebsd-toolchain@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 25968C5D138 for ; Wed, 30 Nov 2016 10:35:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 13DF11697 for ; Wed, 30 Nov 2016 10:35:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAUAZROm018144 for ; Wed, 30 Nov 2016 10:35:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Wed, 30 Nov 2016 10:35:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: cc bug_severity priority assigned_to flagtypes.name bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 10:35:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@FreeBSD.org, | |re@FreeBSD.org Severity|Affects Only Me |Affects Many People Priority|--- |Normal Assignee|gerald@FreeBSD.org |portmgr@FreeBSD.org Flags|maintainer-feedback?(gerald |maintainer-feedback?(portmg |@FreeBSD.org) |r@FreeBSD.org), | |merge-quarterly? Status|New |Open --- Comment #7 from Kubilay Kocak --- All but compiler.mk changes are blanket, re-assign accordingly Can someone please create a separate issue (blocking this one) for the crea= tion of the Errata Notice, and assign it to the correct team/person(s). --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Nov 30 18:38:48 2016 Return-Path: Delivered-To: freebsd-toolchain@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 9853FC5D2F0 for ; Wed, 30 Nov 2016 18:38:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 870091934 for ; Wed, 30 Nov 2016 18:38:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uAUIckOc038976 for ; Wed, 30 Nov 2016 18:38:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Wed, 30 Nov 2016 18:38:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 18:38:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bapt@FreeBSD.org --- Comment #8 from Dimitry Andric --- One question though: why are ports on 10.x using devel/libc++, while libc++= is in base? I would really like to understand the reasoning behind this. IIRC Baptiste added it, so I'm putting him on the CC list. Another way to fix this would be to make the ports that use devel/libc++, a= lso use devel/libcxxrt, in which this problem has already been fixed. E.g, cha= nge the devel/libc++ port so the /usr/local/lib/c++/libstdc++.so linker scripts= it installs contains: GROUP ( /usr/local/lib/libc++.so.1 /usr/local/lib/libcxxrt.so ) and add devel/libcxxrt as a dependency of devel/libc++. This is far easier than an EN, and this workaround can be removed as soon as 9.x and 10.[12] reach end of life. In fact, we should actively try to remo= ve the whole devel/libc++ and devel/libcxxrt ports in the future. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Dec 1 02:03:40 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C8DE4C5E35C for ; Thu, 1 Dec 2016 02:03:40 +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 8DD7411E3 for ; Thu, 1 Dec 2016 02:03:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21460 invoked from network); 1 Dec 2016 02:03:20 -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:03:20 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Thu Dec 1 05:57:25 2016 Return-Path: Delivered-To: freebsd-toolchain@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 8B30CC6274B for ; Thu, 1 Dec 2016 05:57:25 +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 4FE1A1955 for ; Thu, 1 Dec 2016 05:57:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13435 invoked from network); 1 Dec 2016 05:50:44 -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:44 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 05:57:25 -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-toolchain@freebsd.org Thu Dec 1 10:40:03 2016 Return-Path: Delivered-To: freebsd-toolchain@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 ACFA5C60BE1 for ; Thu, 1 Dec 2016 10:40:03 +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 70A421CD5 for ; Thu, 1 Dec 2016 10:40:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17147 invoked from network); 1 Dec 2016 10:40:46 -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:40:46 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Thu Dec 1 22:52:48 2016 Return-Path: Delivered-To: freebsd-toolchain@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 BBC6EC61CA4 for ; Thu, 1 Dec 2016 22:52:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 AAC34191A for ; Thu, 1 Dec 2016 22:52:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB1Mqlct040413 for ; Thu, 1 Dec 2016 22:52:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference Date: Thu, 01 Dec 2016 22:52:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bapt@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 22:52:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214863 --- Comment #9 from Baptiste Daroussin --- well this is a bug :) They should not --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Dec 2 04:57:38 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C03A6C6114D for ; Fri, 2 Dec 2016 04:57:38 +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 805291609 for ; Fri, 2 Dec 2016 04:57:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3660 invoked from network); 2 Dec 2016 04:57:23 -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:23 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Fri Dec 2 08:12:41 2016 Return-Path: Delivered-To: freebsd-toolchain@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 59963C61DE0 for ; Fri, 2 Dec 2016 08:12:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-53.reflexion.net [208.70.210.53]) (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 1D1671DCA for ; Fri, 2 Dec 2016 08:12:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4194 invoked from network); 2 Dec 2016 08:12:40 -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:12:40 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Fri Dec 2 10:29:49 2016 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Fri Dec 2 22:11:05 2016 Return-Path: Delivered-To: freebsd-toolchain@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 48FA3C624AD for ; Fri, 2 Dec 2016 22:11:05 +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 0BEBD1764 for ; Fri, 2 Dec 2016 22:11:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10943 invoked from network); 2 Dec 2016 21:10:43 -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:10:43 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 22:11:05 -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-toolchain@freebsd.org Sat Dec 3 03:38:54 2016 Return-Path: Delivered-To: freebsd-toolchain@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 1B414C630BE for ; Sat, 3 Dec 2016 03:38:54 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 DB6AB11F9 for ; Sat, 3 Dec 2016 03:38:53 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-oi0-x22d.google.com with SMTP id w63so287752216oiw.0 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=Ir2tGPT4X+Xmj0kFcbxmUhHrqnyU/sOQeDAUE6pwPGbpSZ311dGN7ykffBogWLA1pY Wn603RfoF4A8MMz8gIYTROFmOgpJQIzRalABHs6lKLFdJ6+Ch6TyVFuoTgKFA2HZ4k2O PCTQ0WCprZ2dwhksk7HAxLKlNNjVDy8F76IkVHIERitfMUuRkiHkMnBJ0jyu1TCxIQs6 YXZjsQ7JaQQ7E13vciZdeGbPouaRR2vD1YzwZ0zI5fPVXVSOvRv3YDt+BqsrftYiYS8C n+19SmtEc6Uejkpa/bPqrvIXark5/0D2Xze8S1xPs55qDkDTyfhvvxwnyQS3ggd5T/kT DzGQ== X-Gm-Message-State: AKaTC01W6mUYJZfCMOAW4iWsjkZzl9Ahfvvj8vSfKfbFlkSEmE7gs1lUVTQ3FFVFxWNgWSfXGvEDrSv+L+DIMg== 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sat Dec 3 05:26:26 2016 Return-Path: Delivered-To: freebsd-toolchain@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 31E8BC643CC for ; Sat, 3 Dec 2016 05:26:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 E9D671E25 for ; Sat, 3 Dec 2016 05:26:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12771 invoked from network); 3 Dec 2016 05:26:03 -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:03 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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 From owner-freebsd-toolchain@freebsd.org Sat Dec 3 22:56:02 2016 Return-Path: Delivered-To: freebsd-toolchain@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 DAD82C64CE5 for ; Sat, 3 Dec 2016 22:56:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 BF575160 for ; Sat, 3 Dec 2016 22:56:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB3Mu2mB071463 for ; Sat, 3 Dec 2016 22:56:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Sat, 03 Dec 2016 22:56:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 22:56:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 --- Comment #3 from Mark Millard --- Created attachment 177643 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177643&action= =3Dedit List Support/Atomic.cpp in libllvmminimal/Makefile This allowed an old PowerMac G5 to buildworld ( WITHOUT_LIB32=3D ), installworld, reboot via clang 3.9.0 on: # uname -paKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r309179M: Mon Nov 28 01:23:26 PST 2016=20=20=20=20 markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain_kernel/powerpc.powerpc6= 4/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200017 1200017 (with what later was -r309201 manually applied) using: -r416639 of devel/binutils and -r407342 of devel/powerpc-binutils (slave port tracks devel/binutils) (avoiding 2.47 vintages) with: Script started on Fri Dec 2 18:40:48 2016 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-clang_altbinutils.power= pc64-host WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.p= owerpc64 make -j 5 buildworld and: # more ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.powerpc64-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 # # # From based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang -B ${CROSS_BINUTILS_PREFIX} CXX=3D/usr/bin/clang++ -B ${CROSS_BINUTILS_PREFIX} CPP=3D/usr/bin/clang-cpp -B ${CROSS_BINUTILS_PREFIX} .export CC .export CXX .export CPP AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif The powerpc64 was already running head -r309179 via a cross build ( WITHOUT_LIB32=3D ) from an amd64 context. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 3 23:01:27 2016 Return-Path: Delivered-To: freebsd-toolchain@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 8055AC65011 for ; Sat, 3 Dec 2016 23:01:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 6F3176E2 for ; Sat, 3 Dec 2016 23:01:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB3N1R64006010 for ; Sat, 3 Dec 2016 23:01:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Sat, 03 Dec 2016 23:01:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 23:01:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #3) Note: Roman Divacky had requested that I ignore my worries about the X86... file names and just try the patch and rebuild: On 2016-Dec-2, at 2:52 AM, Roman Divacky wrote: Can you try to add Atomic.cpp to lib/clang/libllvmminimal/Makefile ? So I did and it allowed the WITHOUT_LIB32=3D style build to work self-hosted on the powerpc64 under the minor variant of head -r309179 . --=20 You are receiving this mail because: You are the assignee for the bug.=