From owner-freebsd-toolchain@freebsd.org Sun Oct 8 00:47:42 2017 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 1C9DBE46361 for ; Sun, 8 Oct 2017 00:47:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 42677655B9 for ; Sun, 8 Oct 2017 00:47:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7166 invoked from network); 8 Oct 2017 00:47:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 00:47:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 20:47:39 -0400 (EDT) Received: (qmail 1508 invoked from network); 8 Oct 2017 00:47:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 00:47:39 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E50E9EC87FB for ; Sat, 7 Oct 2017 17:47:38 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Exceptions Handling on PPC64 with clang - gnu ld bug identified Message-Id: <331A07C5-E87B-4644-B716-217EC05BBD39@dsl-only.net> Date: Sat, 7 Oct 2017 17:47:38 -0700 To: FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 00:47:42 -0000 Roman Divacky rdivacky at freebsd.org wrote on Sat Oct 7 10:03:10 UTC 2017 : > In a followup to = https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html= > =20 > I attempted to fix gnu ld in base to fix the wrongly set bit. >=20 > The following patch=20 > http://www.vlakno.cz/~rdivacky/ppc64.exceptions.fix.patch >=20 > switches a few computations to happen in 64bits instead of 32bit and = fixes the > wrong personality/LDSA info in binaries. >=20 > As a result clang compiled/assembled c++ binaries with EH start to = work for me. >=20 > Can someone verify this works for everyone? I can see the same cast in = upstream > binutils but in a couple more places, so this is probably not the = final answer > but is good enough for me. Just for the record: in a separate exchange it was realized that: A) This was for a context of a buildworld that was built via gcc 4.2.1 and being able to use clang in such a context. B) This is insufficient to fully fix a buildworld that was built via clang and then use either clang or gcc (such as gcc7) to generate code bound to the system libc++ and libcxxrt for code that throws C++ exceptions. A clang-based builworld results in problems in libc++ and/or libcxxrt for handling thrown C++ exceptions. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 02:38:49 2017 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 103BFE48FE1 for ; Sun, 8 Oct 2017 02:38:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 997E881A10 for ; Sun, 8 Oct 2017 02:38:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2205 invoked from network); 8 Oct 2017 02:38:46 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 02:38:46 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 22:38:46 -0400 (EDT) Received: (qmail 13891 invoked from network); 8 Oct 2017 02:38:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 02:38:46 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B9A62EC8559; Sat, 7 Oct 2017 19:38:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: devel/powerpc64-xtoolchain-gcc on powerpc64 failed to buildkernel: .ERROR_TARGET='ath_hal_ar5212.kld': ctfmerge.13434.core generated for SIGSEGV Message-Id: Date: Sat, 7 Oct 2017 19:38:44 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 02:38:49 -0000 My attempt to buildworld buildkernel via devel/powerpc64-xtoolchain-gcc material via my historical technique failed during buildkernel as follows. First: a little context. . . # uname -apKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r324071M powerpc = powerpc64 1200047 1200047 The buidworld and buildkernel for the above was via system-clang from head -r324071 as well. # svnlite info /usr/ports/ | grep "Re[plv]" = = =20 Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 450478 Last Changed Rev: 450478 # pkg info | egrep -i "(gcc|binutil)" binutils-2.28,1 GNU binary tools gcc7-7.2.0_1 GNU Compiler Collection 7 powerpc64-binutils-2.28,1 GNU binutils for powerpc64 = cross-development powerpc64-gcc-6.3.0 Cross GNU Compiler Collection for = powerpc64 powerpc64-xtoolchain-gcc-0.2 Pre seeded toolchain to cross build = FreeBSD base [powerpc64 "self hosted cross development" is in use here. I cause gcc7 to be treated as the host compiler and powerpc64-gcc to be treated as the cross compiler.] [Note that powerpc64-gcc/g++ is passed -v in the later log file material (via CFLAGS.gcc) so lots of context details are shown.] Second: the failure as seen via /var/crash/ . . . -rw------- 1 root wheel 10002432 Oct 7 09:43:14 2017 = ctfmerge.13434.core instead of directly having a ld failure. And: # /usr/libexec/gdb = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/bi= n/ctfmerge /var/crash/ctfmerge.13434.core . . . Core was generated by `ctfmerge -L VERSION -g -o ath_hal_ar5212.kld = ah_osdep_ar5212.o ar5212_ani.o ar52'. Program terminated with signal 11, Segmentation fault. #0 0x000000001009a164 in .memset () [New Thread 508f6a00 (LWP 100299/)] [New Thread 508f6500 (LWP 100298/)] [New Thread 508f6000 (LWP 100237/)] (gdb) info threads * 3 Thread 508f6000 (LWP 100237/) 0x000000001009a164 in = .memset () 2 Thread 508f6500 (LWP 100298/) 0x00000000100346a0 in = .thread_start () 1 Thread 508f6a00 (LWP 100299/) 0x00000000100346a0 in = .thread_start () (gdb) bt #0 0x000000001009a164 in .memset () #1 0x0000000010076d2c in .__libc_allocate_tls () #2 0x0000000010040c58 in ._tcb_ctor () #3 0x000000001003fa9c in ._thr_alloc () #4 0x0000000010033e30 in ._pthread_create () #5 0x0000000010000b6c in .main () #6 0x000000001000147c in ._start () (gdb) info reg pc pc 0x1009a164 269066596 (gdb) disass Dump of assembler code for function .memset: 0x000000001009a0a4 <.memset+0>: cmpldi r5,11 . . . 0x000000001009a138 <.memset+148>: b 0x1009a184 <.memset+224> 0x000000001009a13c <.memset+152>: rlwinm r11,r10,2,29,29 0x000000001009a140 <.memset+156>: clrldi r9,r10,63 0x000000001009a144 <.memset+160>: std r30,-16(r1) 0x000000001009a148 <.memset+164>: addi r30,r6,4 0x000000001009a14c <.memset+168>: subf r0,r11,r7 0x000000001009a150 <.memset+172>: subf r12,r9,r10 0x000000001009a154 <.memset+176>: addi r11,r6,-8 0x000000001009a158 <.memset+180>: add r10,r6,r0 0x000000001009a15c <.memset+184>: addi r12,r12,-2 0x000000001009a160 <.memset+188>: addi r0,r30,8 0x000000001009a164 <.memset+192>: stwu r8,8(r11) 0x000000001009a168 <.memset+196>: stw r8,0(r30) 0x000000001009a16c <.memset+200>: cmpldi r12,0 0x000000001009a170 <.memset+204>: mr r30,r0 0x000000001009a174 <.memset+208>: bne+ 0x1009a15c <.memset+184> (gdb) info reg r11 r11 0x50908ff8 1351651320 (gdb) x/gx 8+0x50908ff8 0x50909000: Cannot access memory at address 0x50909000 (gdb) x/gx 0x50908ff8 0x50908ff8: 0x0000000000000000 So memset seems to have been told to wonder off outside the mapped pages. ( /usr/local/bin/gdb gets its own SIGSEGV during bt so I used /usr/libexec/gdb that generally works better for the powerpc families as things are.) # file = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/bi= n/ctfmerge = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/bi= n/ctfmerge: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, = version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200047), = FreeBSD-style, not stripped Third: the log file content. . . --- all_subdir_ath_hal_ar5212 --- . . . Building = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/sys/GENERI= C64vtsc-NODBG/modules/usr/src/sys/modules/ath_hal_ar5212/ath_hal_ar5212.kl= d . . . --- all_subdir_ath_hal_ar5212 --- --- ath_hal_ar5212.kld --- Segmentation fault (core dumped) *** [ath_hal_ar5212.kld] Error code 139 make[4]: stopped in /usr/src/sys/modules/ath_hal_ar5212 .ERROR_TARGET=3D'ath_hal_ar5212.kld' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc6= 4/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/ath_hal_ar52= 12/ath_hal_ar5212.kld.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'/usr/local/powerpc64-freebsd/bin/ld -m elf64ppc_fbsd -d = -warn-common --build-id=3Dsha1 -r -d -o ath_hal_ar5212.kld = ah_osdep_ar5212.o ar5212_ani.o ar5212_attach.o ar5212_beacon.o = ar5212_eeprom.o ar5212_gpio.o ar5212_interrupts.o ar5212_keycache.o = ar5212_misc.o ar5212_phy.o ar5212_power.o ar5212_recv.o ar5212_reset.o = ar5212_rfgain.o ar5212_xmit.o ar5111.o ar5112.o ar2413.o ar2425.o = ar5413.o; ctfmerge -L VERSION -g -o ath_hal_ar5212.kld ah_osdep_ar5212.o = ar5212_ani.o ar5212_attach.o ar5212_beacon.o ar5212_eeprom.o = ar5212_gpio.o ar5212_interrupts.o ar5212_keycache.o ar5212_misc.o = ar5212_phy.o ar5212_power.o ar5212_recv.o ar5212_reset.o ar5212_rfgain.o = ar5212_xmit.o ar5111.o ar5112.o ar2413.o ar2425.o ar5413.o; :> = export_syms; awk -f /usr/src/sys/conf/kmod_syms.awk ath_hal_ar5212.kld = export_syms | xargs -J% /usr/local/powerpc64-freebsd/bin/objcopy % = ath_hal_ar5212.kld;' .CURDIR=3D'/usr/src/sys/modules/ath_hal_ar5212' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src= /sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/ath_hal_ar5212' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc6= 4/usr/src/sys/GENERIC64vtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tm= p/legacy/usr/sbin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/= usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.p= owerpc64/usr/src/tmp/legacy/bin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powe= rpc.powerpc64/usr/src/tmp/usr/sbin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/p= owerpc.powerpc64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/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-xtoolchain-gcc.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/sys/modules/ath_hal_ar5212/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.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/sys/modules/ath_hal_ar5212/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk = /usr/src/sys/conf/config.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/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/ath_hal_ar5212 /usr/src/sys/dev/ath = /usr/src/sys/dev/ath/ath_hal /usr/src/sys/dev/ath/ = /usr/src/sys/dev/ath/ath_hal/ar5212 = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/sys/GENERI= C64vtsc-NODBG' 1 error make[4]: stopped in /usr/src/sys/modules/ath_hal_ar5212 .ERROR_TARGET=3D'ath_hal_ar5212.kld' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc6= 4/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/ath_hal_ar52= 12/ath_hal_ar5212.kld.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'/usr/local/powerpc64-freebsd/bin/ld -m elf64ppc_fbsd -d = -warn-common --build-id=3Dsha1 -r -d -o ath_hal_ar5212.kld = ah_osdep_ar5212.o ar5212_ani.o ar5212_attach.o ar5212_beacon.o = ar5212_eeprom.o ar5212_gpio.o ar5212_interrupts.o ar5212_keycache.o = ar5212_misc.o ar5212_phy.o ar5212_power.o ar5212_recv.o ar5212_reset.o = ar5212_rfgain.o ar5212_xmit.o ar5111.o ar5112.o ar2413.o ar2425.o = ar5413.o; ctfmerge -L VERSION -g -o ath_hal_ar5212.kld ah_osdep_ar5212.o = ar5212_ani.o ar5212_attach.o ar5212_beacon.o ar5212_eeprom.o = ar5212_gpio.o ar5212_interrupts.o ar5212_keycache.o ar5212_misc.o = ar5212_phy.o ar5212_power.o ar5212_recv.o ar5212_reset.o ar5212_rfgain.o = ar5212_xmit.o ar5111.o ar5112.o ar2413.o ar2425.o ar5413.o; :> = export_syms; awk -f /usr/src/sys/conf/kmod_syms.awk ath_hal_ar5212.kld = export_syms | xargs -J% /usr/local/powerpc64-freebsd/bin/objcopy % = ath_hal_ar5212.kld;' .CURDIR=3D'/usr/src/sys/modules/ath_hal_ar5212' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src= /sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/ath_hal_ar5212' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc6= 4/usr/src/sys/GENERIC64vtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tm= p/legacy/usr/sbin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/= usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.p= owerpc64/usr/src/tmp/legacy/bin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powe= rpc.powerpc64/usr/src/tmp/usr/sbin:/usr/obj/powerpc64vtsc_xtoolchain-gcc/p= owerpc.powerpc64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/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-xtoolchain-gcc.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/sys/modules/ath_hal_ar5212/Makefile = /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.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/sys/modules/ath_hal_ar5212/../Makefile.inc = /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk = /usr/src/sys/conf/config.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/sys/conf/kern.mk' .PATH=3D'. /usr/src/sys/modules/ath_hal_ar5212 /usr/src/sys/dev/ath = /usr/src/sys/dev/ath/ath_hal /usr/src/sys/dev/ath/ = /usr/src/sys/dev/ath/ath_hal/ar5212 = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/sys/GENERI= C64vtsc-NODBG' *** [all_subdir_ath_hal_ar5212] Error code 2 Finally: other details. . . # more = ~/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_clang_x= toolchain-gcc-powerpc64-host.sh kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch= ain-gcc-powerpc64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" \ SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain-gcc.powerp= c64-host" \ WITH_META_MODE=3Dyes \ = MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc6= 4" \ make $* Note: Variations of the below have been in use for along time but it been some time since I've checked if devel/powerpc64-xtoolchain-gcc was working. The below is set up to use lang/gcc7 as the host- compiler/toolchain and devel/powerpc64-xtoolchain-gcc material as the cross-compiler/toolchain. The src.conf file has history going back to my using lang/gcc49 as the host-compiler instead, updated as things have progressed. # more = /root/src.configs/src.conf.powerpc64-xtoolchain-gcc.powerpc64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3D${TO_TYPE} TOOLS_FROM_TYPE=3D${FROM_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 # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried # but the LIB32 does not work [crtbeginS code problem(s)] WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Avoid db_trace.o getting: # calling '__builtin_frame_address' with a nonzero argument is unsafe # as an error? Other such points as well. WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=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_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP 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 # # # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but not xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc7 -L/usr/lib CXX=3Denv C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++7 -std=3Dc++11 = -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp7 .export CC .export CXX .export CPP = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size #NO-SUCH: = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings STRINGS=3D/usr/local/bin/strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif # more ~/src.configs/make.conf=20 CFLAGS.gcc+=3D -v =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 03:33:09 2017 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 DF622E248F1 for ; Sun, 8 Oct 2017 03:33:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 2E6A568A85 for ; Sun, 8 Oct 2017 03:33:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28380 invoked from network); 8 Oct 2017 03:33:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 03:33:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 23:33:07 -0400 (EDT) Received: (qmail 8290 invoked from network); 8 Oct 2017 03:33:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 03:33:06 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1EAF3EC8559; Sat, 7 Oct 2017 20:33:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc Date: Sat, 7 Oct 2017 20:33:05 -0700 References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> <20171007102151.GA84155@vlakno.cz> To: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current In-Reply-To: Message-Id: <6B5AB934-1F8F-49F0-90F6-C4F9C48787E6@dsl-only.net> X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 03:33:10 -0000 It turns out that /usr/local/bin/gdb crashing=20 for the clang-built powerpc64 world is again due to C++ exceptions being thrown, this time in gdb80 itself. This helps explain why for clang-based buildworld experiments /usr/libexec/gdb is a better alternative currently for the powerpc families. Again the _Unwind_SetGR use in __gxx_personality_v0 fails: # ls -lT /usr/local/bin/gdb* lrwxr-xr-x 1 root wheel 5 Sep 29 15:25:15 2017 = /usr/local/bin/gdb -> gdb80 -r-xr-xr-x 1 root wheel 97577168 Sep 29 15:25:15 2017 = /usr/local/bin/gdb80 lrwxr-xr-x 1 root wheel 5 Sep 29 15:25:15 2017 = /usr/local/bin/gdbtui80 -> gdb80 # ldd /usr/local/bin/gdb80=20 /usr/local/bin/gdb80: libreadline.so.7 =3D> /usr/local/lib/libreadline.so.7 = (0x50e80000) libncurses.so.8 =3D> /lib/libncurses.so.8 (0x50ef7000) libkvm.so.7 =3D> /lib/libkvm.so.7 (0x50f61000) libutil.so.9 =3D> /lib/libutil.so.9 (0x50f83000) libm.so.5 =3D> /lib/libm.so.5 (0x50fad000) libexpat.so.1 =3D> /usr/local/lib/libexpat.so.1 (0x50fe5000) liblzma.so.5 =3D> /usr/lib/liblzma.so.5 (0x5102a000) libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x5105d000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5118a000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x511b1000) libc.so.7 =3D> /lib/libc.so.7 (0x511d6000) libncursesw.so.8 =3D> /lib/libncursesw.so.8 (0x51528000) libelf.so.2 =3D> /lib/libelf.so.2 (0x515ac000) libthr.so.3 =3D> /lib/libthr.so.3 (0x515da000) # /usr/libexec/gdb /usr/local/bin/gdb80 /var/crash/gdb80.14502.core=20 . . . Core was generated by `/usr/local/bin/gdb = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/s'. Program terminated with signal 11, Segmentation fault. . . . (gdb) bt #0 0x00000000511b5c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1374378080) at = unwind-dw2-fde.h:162 #1 0x000000005119f194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x51eb5860,=20 context=3D0xffffffffffffb420) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x00000000511b6a60 in _Unwind_RaiseException_Phase2 (exc=3D0x51eb5860,= context=3D0xffffffffffffb420) at unwind.inc:66 #3 0x00000000511b6548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005119e4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x00000000102be040 in throw_exception () at common-exceptions.c:303 #6 0x00000000102be1dc in throw_it (reason=3D1374378080, = error=3D4294947872, fmt=3D, ap=3D) at common-exceptions.c:373 #7 0x00000000102be0a4 in throw_verror (error=3D, = fmt=3D, ap=3D) at = common-exceptions.c:379 #8 0x00000000102be258 in throw_error (error=3DGDB_NO_ERROR, fmt=3D0x18 =
) at common-exceptions.c:394 #9 0x0000000010279bf8 in call_site_for_pc (gdbarch=3D, pc=3D) at block.c:241 #10 0x00000000102e93e0 in call_site_find_chain (gdbarch=3D, caller_pc=3D, callee_pc=3D) at dwarf2loc.c:1057 #11 0x00000000102e4800 in dwarf2_tailcall_sniffer_first = (this_frame=3D0x51eb5808, tailcall_cachep=3D0x51eb5860, = entry_cfa_sp_offsetp=3D0xffffffffffffb420) at = dwarf2-frame-tailcall.c:387 #12 0x00000000102e32b8 in = ._ZL26dwarf2_frame_prev_registerP10frame_infoPPvi () at = __split_buffer:311 #13 0x0000000010340464 in frame_unwind_register_value (frame=3D, regnum=3D) at frame.c:1200 #14 0x0000000010340148 in frame_register_unwind (frame=3D0x0, = regnum=3D, optimizedp=3D0x51eb5860, = unavailablep=3D0x51eb5808, lvalp=3D0x514077a0, addrp=3D0x51eb5808, = realnump=3D0x6,=20 bufferp=3D0xffffffffffffb420 "") at frame.c:1102 #15 0x0000000010341ddc in get_prev_frame_always_1 = (this_frame=3D0xffffffffffffb420) at frame.c:1840 #16 0x000000001033e878 in get_prev_frame_always = (this_frame=3D0xffffffffffffb420) at frame.c:2092 #17 0x000000001033e110 in get_prev_frame (this_frame=3D0xffffffffffffb420)= at frame.c:2345 #18 0x0000000010419464 in backtrace_command (arg=3D, from_tty=3D1374378080) at stack.c:1830 #19 0x00000000101e3654 in do_cfunc (c=3D, args=3D0x0,= from_tty=3D24) at cli/cli-decode.c:106 #20 0x00000000101e67b0 in cmd_func (cmd=3D0x0, args=3D0x18
, from_tty=3D) at = cli/cli-decode.c:1896 #21 0x000000001046497c in execute_command (p=3D, = from_tty=3D1374377992) at top.c:674 #22 0x000000001032e398 in command_handler (command=3D0xffffffffffffb420 = "") at event-top.c:590 #23 0x000000001032e788 in command_line_handler (rl=3D) at event-top.c:780 #24 0x000000001032dc54 in gdb_rl_callback_handler (rl=3D) at event-top.c:213 #25 0x0000000050ec5950 in rl_callback_read_char () at ../callback.c:283 #26 0x000000001032f560 in gdb_rl_callback_read_char_wrapper_noexcept () = at event-top.c:175 #27 0x000000001032d84c in gdb_rl_callback_read_char_wrapper = (client_data=3D) at event-top.c:192 #28 0x000000001032e14c in stdin_event_handler (error=3D, client_data=3D0xffffffffffffb420) at event-top.c:518 #29 0x000000001032d690 in handle_file_event = (file_ptr=3D0xffffffffffffb420, ready_mask=3D1374378080) at = event-loop.c:733 #30 0x000000001032c830 in gdb_wait_for_event (block=3D) at common-exceptions.h:220 #31 0x000000001032c2c4 in gdb_do_one_event () at event-loop.c:347 #32 0x000000001032c940 in start_event_loop () at event-loop.c:371 #33 0x00000000103a674c in captured_command_loop (data=3D) at main.c:325 #34 0x000000001032fd50 in catch_errors (func=3D, = func_args=3D0x6, errstring=3D0xffffffffffffb420 "", mask=3D1374377992) = at exceptions.c:236 #35 0x00000000103a61b4 in gdb_main (args=3D) at = main.c:1150 #36 0x000000001000bc38 in main (argc=3D, = argv=3D0xffffffffffffb420) at gdb.c:38 #37 0x000000001000b938 in _start (argc=3D1374377992, argv=3D0x51eb5860, = env=3D0xffffffffffffb420, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 #38 0x0000000050e49b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Current language: auto; currently minimal =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 04:46:05 2017 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 D8D99E266F2 for ; Sun, 8 Oct 2017 04:46:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 895797C327 for ; Sun, 8 Oct 2017 04:46:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7169 invoked from network); 8 Oct 2017 04:46:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 04:46:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 00:46:03 -0400 (EDT) Received: (qmail 4364 invoked from network); 8 Oct 2017 04:46:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 04:46:02 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 333FBEC8FB8; Sat, 7 Oct 2017 21:46:02 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: powerpc64 /usr/bin/ld crashes during buildworld: ppc64_elf_tls_optimize gets signal 11 Message-Id: Date: Sat, 7 Oct 2017 21:46:01 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 04:46:06 -0000 Because of the following I've had to use a ports binutils (such as devel/powerpc64-binutils ) instead of the system binutils in order to have a clang-based powerpc64 world do a gcc 4.2.1 based "cross build" (buildworld buildkernel). This was from a clang-based buildworld buildkernel powerpc64 FreeBSD context. It was an attempt to do a gcc 4.2.1 "cross-compiler" based buildworld buildkernel. It did not get very far before (using one of several ld core files as an example): # /usr/libexec/gdb ld /var/crash/ld.26814.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 "powerpc64-marcel-freebsd"... Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o gperf.full = /usr/lib/crt1.o /usr/lib/crti.'. Program terminated with signal 11, Segmentation fault. #0 0x000000001002e148 in ppc64_elf_tls_optimize (obfd=3D, info=3D) at = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf6= 4-ppc.c:7172 7172 for (ent =3D = htab->tls_get_addr->elf.plt.plist; (gdb) bt #0 0x000000001002e148 in ppc64_elf_tls_optimize (obfd=3D, info=3D) at = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf6= 4-ppc.c:7172 #1 0x0000000010001034 in ppc_before_allocation () at = eelf64ppc_fbsd.c:204 #2 0x0000000010009be4 in ldemul_before_allocation () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:= 78 #3 0x0000000010017b00 in lang_process () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:= 5785 #4 0x0000000010021ce0 in main (argc=3D0, argv=3D) = at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:= 459 #5 0x00000000100004a8 in _start (argc=3D0, argv=3D0x50a24fc0, = env=3D0x50f3feb8, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 Current language: auto; currently minimal The source is: if (expecting_tls_get_addr) { struct plt_entry *ent; for (ent =3D htab->tls_get_addr->elf.plt.plist; ent !=3D NULL; ent =3D ent->next) if (ent->addend =3D=3D 0) { if (ent->plt.refcount > 0) { ent->plt.refcount -=3D 1; expecting_tls_get_addr =3D 0; } break; } } (gdb) print htab->tls_get_addr $3 =3D (struct ppc_link_hash_entry *) 0x0 0x1002e124 : beq- 0x1002e4ec = 0x1002e128 : li r3,18 0x1002e12c : li r14,2 0x1002e130 : li r28,0 0x1002e134 : cmpwi r5,0 0x1002e138 : crnot 4*cr5+lt,eq 0x1002e13c : beq- cr2,0x1002e198 = 0x1002e140 : bge- cr5,0x1002e330 = 0x1002e144 : ld r4,544(r22) 0x1002e148 : ld r4,80(r4) 0x1002e14c : cmpldi r4,0 0x1002e150 : beq- 0x1002e16c = (gdb) info reg r5 r5 0x1 1 (I expect that means expecting_tls_get_addr=3D=3D1 .) (gdb) info reg r4 r4 0x0 0 --- _bootstrap-tools-gnu/usr.bin/gperf --- Building = /usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/us= r.bin/gperf/version.o Building = /usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/us= r.bin/gperf/getline.o Building = /usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/us= r.bin/gperf/hash.o Building = /usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/us= r.bin/gperf/gperf.full . . . --- _bootstrap-tools-gnu/usr.bin/gperf --- --- gperf.full --- c++: error: unable to execute command: Segmentation fault (core dumped) c++: error: linker command failed due to signal (use -v to see = invocation) *** [gperf.full] Error code 254 make[3]: stopped in /usr/src/gnu/usr.bin/gperf .ERROR_TARGET=3D'gperf.full' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/sr= c/tmp/usr/src/gnu/usr.bin/gperf/gperf.full.meta' .MAKE.LEVEL=3D'3' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'c++ -O2 -pipe -g -Qunused-arguments = -I/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy/usr/i= nclude -I/usr/src/contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf = -Wno-c++11-extensions -static = -L/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy/usr/l= ib -o gperf.full bool-array.o hash-table.o input.o keyword-list.o = keyword.o main.o options.o output.o positions.o search.o version.o = getline.o hash.o -legacy;' .CURDIR=3D'/usr/src/gnu/usr.bin/gperf' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr= /src/gnu/usr.bin/gperf' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/sr= c/tmp' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/leg= acy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_gcc421/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-gcc421-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/gnu/usr.bin/gperf/Makefile /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.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/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/gnu/usr.bin/gperf/../Makefile.inc = /usr/src/gnu/usr.bin/gperf/../../Makefile.inc = /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/gnu/usr.bin/gperf /usr/src/contrib/gperf/src = /usr/src/contrib/gperf/lib /usr/src/contrib/gperf/doc' 1 error make[3]: stopped in /usr/src/gnu/usr.bin/gperf .ERROR_TARGET=3D'gperf.full' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/sr= c/tmp/usr/src/gnu/usr.bin/gperf/gperf.full.meta' .MAKE.LEVEL=3D'3' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'c++ -O2 -pipe -g -Qunused-arguments = -I/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy/usr/i= nclude -I/usr/src/contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf = -Wno-c++11-extensions -static = -L/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy/usr/l= ib -o gperf.full bool-array.o hash-table.o input.o keyword-list.o = keyword.o main.o options.o output.o positions.o search.o version.o = getline.o hash.o -legacy;' .CURDIR=3D'/usr/src/gnu/usr.bin/gperf' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr= /src/gnu/usr.bin/gperf' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/sr= c/tmp' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/leg= acy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_gcc421/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-gcc421-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/gnu/usr.bin/gperf/Makefile /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.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/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/gnu/usr.bin/gperf/../Makefile.inc = /usr/src/gnu/usr.bin/gperf/../../Makefile.inc = /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/gnu/usr.bin/gperf /usr/src/contrib/gperf/src = /usr/src/contrib/gperf/lib /usr/src/contrib/gperf/doc' *** [_bootstrap-tools-gnu/usr.bin/gperf] Error code 2 make[2]: stopped in /usr/src .ERROR_TARGET=3D'_bootstrap-tools-gnu/usr.bin/gperf' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'.PHONY' .CURDIR=3D'/usr/src' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr= /src' .TARGETS=3D'bootstrap-tools' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/sr= c/tmp' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/leg= acy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/tmp/usr/src/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-gcc421-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/Makefile.inc1 = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/Makefile.libcompat /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk' .PATH=3D'. /usr/src' 4 errors make[2]: stopped in /usr/src .ERROR_TARGET=3D'_bootstrap-tools-gnu/usr.bin/gperf' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'.PHONY' .CURDIR=3D'/usr/src' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr= /src' .TARGETS=3D'bootstrap-tools' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/sr= c/tmp' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/leg= acy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/tmp/usr/src/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-gcc421-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/Makefile.inc1 = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/Makefile.libcompat /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk' .PATH=3D'. /usr/src' *** [_bootstrap-tools] Error code 2 Other examples include: Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o = make-roken.full /usr/lib/crt1.o /usr/lib/'. Program terminated with signal 11, Segmentation fault. #0 0x000000001002e148 in ppc64_elf_tls_optimize (obfd=3D, info=3D) at = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf6= 4-ppc.c:7172 7172 for (ent =3D = htab->tls_get_addr->elf.plt.plist; (gdb) bt #0 0x000000001002e148 in ppc64_elf_tls_optimize (obfd=3D, info=3D) at = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf6= 4-ppc.c:7172 #1 0x0000000010001034 in ppc_before_allocation () at = eelf64ppc_fbsd.c:204 #2 0x0000000010009be4 in ldemul_before_allocation () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:= 78 #3 0x0000000010017b00 in lang_process () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:= 5785 #4 0x0000000010021ce0 in main (argc=3D0, argv=3D) = at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:= 459 #5 0x00000000100004a8 in _start (argc=3D0, argv=3D0x50a22400, = env=3D0x50bb3658, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 Current language: auto; currently minimal Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o = strfile.full /usr/lib/crt1.o /usr/lib/crt'. Program terminated with signal 11, Segmentation fault. #0 0x000000001002e148 in ppc64_elf_tls_optimize (obfd=3D, info=3D) at = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf6= 4-ppc.c:7172 7172 for (ent =3D = htab->tls_get_addr->elf.plt.plist; (gdb) bt #0 0x000000001002e148 in ppc64_elf_tls_optimize (obfd=3D, info=3D) at = /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf6= 4-ppc.c:7172 #1 0x0000000010001034 in ppc_before_allocation () at = eelf64ppc_fbsd.c:204 #2 0x0000000010009be4 in ldemul_before_allocation () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:= 78 #3 0x0000000010017b00 in lang_process () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:= 5785 #4 0x0000000010021ce0 in main (argc=3D0, argv=3D) = at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:= 459 #5 0x00000000100004a8 in _start (argc=3D0, argv=3D0x50a222c0, = env=3D0x50bdbfb8, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 Current language: auto; currently minimal It appears that clang 5 outputs something that the system ld does not expect, such that htab->tls_get_addr=3D=3DNULL is involved when expecting_tls_get_addr=3D=3D1 . Details for the failing build's context: # more = ~/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_gcc421_boots= trap-powerpc64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_gcc421_bootstrap-p= owerpc64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" \ SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-gcc421-bootstrap.powe= rpc64-host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64" \ make $* # more = /root/src.configs/src.conf.powerpc64-gcc421-bootstrap.powerpc64-host TO_TYPE=3Dpowerpc64 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITHOUT_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG_FULL=3D WITHOUT_CLANG_EXTRAS=3D WITHOUT_LLD=3D WITHOUT_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GCC_IS_CC=3D WITH_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D Making it work means adding (for example): TOOLS_TO_TYPE=3D${TO_TYPE} . . . # # # 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 # CFLAGS.clang+=3D -B${CROSS_BINUTILS_PREFIX} CXXFLAGS.clang+=3D -B${CROSS_BINUTILS_PREFIX} .export CFLAGS.clang .export CXXFLAGS.clang AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar 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 NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld .export LD .endif As I remember, back in clang 4 days I did not have to do such a thing (or it would have been already be in place in my environment for these experiments). It may well be that 32-bit powerpc would not have this issue. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 10:11:34 2017 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 3BADDE303B5 for ; Sun, 8 Oct 2017 10:11: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 DB7C481263 for ; Sun, 8 Oct 2017 10:11:33 +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 v98ABVPo046076 for ; Sun, 8 Oct 2017 10:11:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222641] www/firefox: OPTIMIZED_CFLAGS=off build fails: libgkrust.a: could not read symbols Date: Sun, 08 Oct 2017 10:11:31 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pi@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ 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: Sun, 08 Oct 2017 10:11:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222641 --- Comment #26 from Kurt Jaeger --- (In reply to Kurt Jaeger from comment #18) I was not able to catch the libgkrust file as of now. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Oct 8 11:34:38 2017 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 47878E323DE for ; Sun, 8 Oct 2017 11:34:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 B07146F816 for ; Sun, 8 Oct 2017 11:34:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12115 invoked from network); 8 Oct 2017 11:34:30 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 11:34:30 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 07:34:30 -0400 (EDT) Received: (qmail 17934 invoked from network); 8 Oct 2017 11:34:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 11:34:30 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BB325EC9220; Sun, 8 Oct 2017 04:34:29 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Message-Id: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> Date: Sun, 8 Oct 2017 04:34:29 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 11:34:38 -0000 =46rom a dwarfdump's _Unwind_RaiseException information from a clang/clang++ 5 based compile: 91 DW_CFA_offset_extended r97 -496 (62 * -8) 94 DW_CFA_offset_extended r98 -480 (60 * -8) 97 DW_CFA_offset_extended r99 -464 (58 * -8) 100 DW_CFA_offset_extended r100 -448 (56 * -8) 103 DW_CFA_offset_extended r101 -432 (54 * -8) 106 DW_CFA_offset_extended r102 -416 (52 * -8) 109 DW_CFA_offset_extended r103 -400 (50 * -8) 112 DW_CFA_offset_extended r104 -384 (48 * -8) 115 DW_CFA_offset_extended r105 -368 (46 * -8) 118 DW_CFA_offset_extended r106 -352 (44 * -8) 121 DW_CFA_offset_extended r107 -336 (42 * -8) 124 DW_CFA_offset_extended r108 -320 (40 * -8) By contrast devel/powerpc64-gcc does not produce any of those. Is this lack of support of some part of an ABI? Is clang going outside the range of the intended ABI? Does FreeBSD's libgcc_s design and implementation handle these additional logical registers? (I've no clue what the logical registers r97-r108 are supposed to match up with in powerpc64 terms.) Supporting notes: r46-r63 are for floating point registers (that have been around for a long time: older powerpc family members). r70 is for having/using the value from "mfcr". r2(?)-r6 are scratch for C++ exception handling. (I originally identified r3-r6. r2 might have a somewhat distinct status?) r14-r31 are for the normal r14 through r31 registers. r65 is standard and heavily used on all(?) routines, not just some libgcc_s ones. (So r65 is not listed below.) In libgcc_s.so.1.full (via powerpc64-gcc): uw_update_context_1: r70 _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_RaiseException_Phase2: (nothing special matched) _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 __deregister_frame_info_bases: r70 _Unwind_Find_FDE: r70 In libgcc_s.so.1.full (via clang): uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_RaiseException_Phase2: r70 _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] __deregister_frame_info_bases: (nothing special matched) _Unwind_Find_FDE: (nothing special matched) clang is missing all the r[2-6] references but the code generated does have the registers in use. Thrown C++ exceptions crash because of the lack of the r2-r6's, dying on a r3 attempt. I have no clue yet what r9[7-9],r10[0-8] are for. _Unwind_Backtrace suggests that none of them are alternate names for scratch registers r[2-6]. I have no clue why _Unwind_RaiseException_Phase2 has a r70 for clang but not for powerpc64-gcc. Or the other way around for __deregister_frame_info_bases and _Unwind_Find_FDE. Which file's implementations are used from what I can tell : uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c _Unwind_Find_FDE: /usr/src/contrib/gcc/unwind-dw2-fde*.c = (unsure) An implication is that GPL Version 2 source code is involved even when clang is the system compiler. Is that what FreeBSD intends for the powerpc families? /* Exception handling and frame unwind runtime interface routines. -*- C = -*- Copyright (C) 2001, 2003 Free Software Foundation, Inc. This file is part of GCC. GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combined executable.) . . . Does libgcc_s.so.1 with its type of use form a "combined executable"? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 13:34:49 2017 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 B3D07E35BDB for ; Sun, 8 Oct 2017 13:34:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 3D2796977F for ; Sun, 8 Oct 2017 13:34:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16511 invoked from network); 8 Oct 2017 13:34:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 13:34:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 09:34:47 -0400 (EDT) Received: (qmail 19223 invoked from network); 8 Oct 2017 13:34:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 13:34:46 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9E437EC8B8D; Sun, 8 Oct 2017 06:34:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Date: Sun, 8 Oct 2017 06:34:44 -0700 References: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> To: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers In-Reply-To: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> Message-Id: <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 13:34:49 -0000 [Looks like r97-r108 are for vr20-vr31 (AltiVec Registers).] On 2017-Oct-8, at 4:34 AM, Mark Millard wrote: > =46rom a dwarfdump's _Unwind_RaiseException information > from a clang/clang++ 5 based compile: >=20 > 91 DW_CFA_offset_extended r97 -496 (62 * -8) > 94 DW_CFA_offset_extended r98 -480 (60 * -8) > 97 DW_CFA_offset_extended r99 -464 (58 * -8) > 100 DW_CFA_offset_extended r100 -448 (56 * -8) > 103 DW_CFA_offset_extended r101 -432 (54 * -8) > 106 DW_CFA_offset_extended r102 -416 (52 * -8) > 109 DW_CFA_offset_extended r103 -400 (50 * -8) > 112 DW_CFA_offset_extended r104 -384 (48 * -8) > 115 DW_CFA_offset_extended r105 -368 (46 * -8) > 118 DW_CFA_offset_extended r106 -352 (44 * -8) > 121 DW_CFA_offset_extended r107 -336 (42 * -8) > 124 DW_CFA_offset_extended r108 -320 (40 * -8) >=20 > By contrast devel/powerpc64-gcc does not produce any > of those. Is this lack of support of some part of an > ABI? Is clang going outside the range of the intended > ABI? ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates that r97-r108 are for vr20-vr31 (AltiVec Registers). [Is AltiVec optional --possibly missing?] So the questions translate into questions about AltiVec support/handling for C++ exceptions. [Note: R70 is supposed to be specific to CR2.] > Does FreeBSD's libgcc_s design and implementation handle > these additional logical registers? . . . So the libgcc_s question traces back to: does it handle AltiVec Registers vr20-vr31 if they are referenced (clang)? Is it well behaved if r97-r108 are not referenced (powerpc64-gcc)? > Supporting notes: >=20 > r46-r63 are for floating point registers (that > have been around for a long time: older > powerpc family members). r46-r63 are for f14-f31. > r70 is for having/using the value from "mfcr". Apparently r70 is supposed to be specific to CR2. > r2(?)-r6 are scratch for C++ exception handling. > (I originally identified r3-r6. r2 might have a > somewhat distinct status?) In normal functions r2-r6 do not get DW_CFA_offset_extended_sf or DW_CFA_offset entries. They are special to some internal exception handling routines. (See later.) > r14-r31 are for the normal r14 through r31 > registers. r97-r108 are for AltiVec Registers vr20-vr31. > r65 is standard and heavily used on all(?) > routines, not just some libgcc_s ones. (So > r65 is not listed below.) r65 for lr. > In libgcc_s.so.1.full (via powerpc64-gcc): >=20 > uw_update_context_1: r70 > _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_RaiseException_Phase2: (nothing special matched) > _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 > __deregister_frame_info_bases: r70 > _Unwind_Find_FDE: r70 So no AltiVec Registers listed. > In libgcc_s.so.1.full (via clang): >=20 > uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) > _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_RaiseException_Phase2: r70 > _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > __deregister_frame_info_bases: (nothing special matched) > _Unwind_Find_FDE: (nothing special matched) So no internal, special-for-excpetion-routines scratch register usage listed (r2-r6). > clang is missing all the r[2-6] references but > the code generated does have the registers in > use. Thrown C++ exceptions crash because of > the lack of the r2-r6's, dying on a r3 attempt. >=20 . . . >=20 > I have no clue why _Unwind_RaiseException_Phase2 > has a r70 for clang but not for powerpc64-gcc. > Or the other way around for __deregister_frame_info_bases > and _Unwind_Find_FDE. >=20 > Which file's implementations are used from > what I can tell : >=20 > uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c > _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc > _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc > _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc > _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc > _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc > _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc > __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c > _Unwind_Find_FDE: /usr/src/contrib/gcc/unwind-dw2-fde*.c = (unsure) >=20 > An implication is that GPL Version 2 source code > is involved even when clang is the system compiler. > Is that what FreeBSD intends for the powerpc > families? >=20 > /* Exception handling and frame unwind runtime interface routines. -*- = C -*- > Copyright (C) 2001, 2003 Free Software Foundation, Inc. >=20 > This file is part of GCC. >=20 > GCC is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2, or (at your option) > any later version. >=20 > In addition to the permissions in the GNU General Public License, = the > Free Software Foundation gives you unlimited permission to link the > compiled version of this file into combinations with other programs, > and to distribute those combinations without any restriction coming > from the use of this file. (The General Public License restrictions > do apply in other respects; for example, they cover modification of > the file, and distribution when not linked into a combined > executable.) >=20 > . . . >=20 > Does libgcc_s.so.1 with its type of use form a "combined executable"? >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 21:24:11 2017 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 D807DE40765 for ; Sun, 8 Oct 2017 21:24:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 3EF806F4BA for ; Sun, 8 Oct 2017 21:24:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29871 invoked from network); 8 Oct 2017 21:24:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 21:24:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 17:24:09 -0400 (EDT) Received: (qmail 6810 invoked from network); 8 Oct 2017 21:24:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 21:24:08 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1AD7DEC952A; Sun, 8 Oct 2017 14:24:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Date: Sun, 8 Oct 2017 14:24:07 -0700 References: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> To: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers , Justin Hibbits , Nathan Whitehorn In-Reply-To: <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 21:24:12 -0000 Quick top note: clang 5 does generate code sequences with AltiVec stvx and lvx instructions where r97-r108 are listed but powerpc64-gcc is not doing so in those same sorts of places. This appears to be a ABI variation across toolchains to me, unless such is fully optional in the ABI somehow. On 2017-Oct-8, at 6:34 AM, Mark Millard wrote: > [Looks like r97-r108 are for vr20-vr31 (AltiVec > Registers).] >=20 > On 2017-Oct-8, at 4:34 AM, Mark Millard = wrote: >=20 >> =46rom a dwarfdump's _Unwind_RaiseException information >> from a clang/clang++ 5 based compile: >>=20 >> 91 DW_CFA_offset_extended r97 -496 (62 * -8) >> 94 DW_CFA_offset_extended r98 -480 (60 * -8) >> 97 DW_CFA_offset_extended r99 -464 (58 * -8) >> 100 DW_CFA_offset_extended r100 -448 (56 * -8) >> 103 DW_CFA_offset_extended r101 -432 (54 * -8) >> 106 DW_CFA_offset_extended r102 -416 (52 * -8) >> 109 DW_CFA_offset_extended r103 -400 (50 * -8) >> 112 DW_CFA_offset_extended r104 -384 (48 * -8) >> 115 DW_CFA_offset_extended r105 -368 (46 * -8) >> 118 DW_CFA_offset_extended r106 -352 (44 * -8) >> 121 DW_CFA_offset_extended r107 -336 (42 * -8) >> 124 DW_CFA_offset_extended r108 -320 (40 * -8) >>=20 >> By contrast devel/powerpc64-gcc does not produce any >> of those. Is this lack of support of some part of an >> ABI? Is clang going outside the range of the intended >> ABI? >=20 > ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates > that r97-r108 are for vr20-vr31 (AltiVec Registers). > [Is AltiVec optional --possibly missing?] >=20 > So the questions translate into questions about > AltiVec support/handling for C++ exceptions. >=20 > [Note: R70 is supposed to be specific to CR2.] >=20 >> Does FreeBSD's libgcc_s design and implementation handle >> these additional logical registers? > . . . >=20 > So the libgcc_s question traces back to: does it > handle AltiVec Registers vr20-vr31 if they are > referenced (clang)? Is it well behaved if r97-r108 > are not referenced (powerpc64-gcc)? >=20 >> Supporting notes: >>=20 >> r46-r63 are for floating point registers (that >> have been around for a long time: older >> powerpc family members). >=20 > r46-r63 are for f14-f31. >=20 >> r70 is for having/using the value from "mfcr". >=20 > Apparently r70 is supposed to be specific to CR2. >=20 >> r2(?)-r6 are scratch for C++ exception handling. >> (I originally identified r3-r6. r2 might have a >> somewhat distinct status?) >=20 > In normal functions r2-r6 do not get > DW_CFA_offset_extended_sf or > DW_CFA_offset entries. They are special > to some internal exception handling > routines. (See later.) >=20 >> r14-r31 are for the normal r14 through r31 >> registers. >=20 > r97-r108 are for AltiVec Registers vr20-vr31. >=20 >> r65 is standard and heavily used on all(?) >> routines, not just some libgcc_s ones. (So >> r65 is not listed below.) >=20 > r65 for lr. >=20 >> In libgcc_s.so.1.full (via powerpc64-gcc): >>=20 >> uw_update_context_1: r70 >> _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_RaiseException_Phase2: (nothing special matched) >> _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 >> __deregister_frame_info_bases: r70 >> _Unwind_Find_FDE: r70 >=20 > So no AltiVec Registers listed. >=20 >> In libgcc_s.so.1.full (via clang): >>=20 >> uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) >> _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_RaiseException_Phase2: r70 >> _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> __deregister_frame_info_bases: (nothing special matched) >> _Unwind_Find_FDE: (nothing special matched) >=20 > So no internal, special-for-excpetion-routines > scratch register usage listed (r2-r6). >=20 >> clang is missing all the r[2-6] references but >> the code generated does have the registers in >> use. Thrown C++ exceptions crash because of >> the lack of the r2-r6's, dying on a r3 attempt. >>=20 > . . . >>=20 >> I have no clue why _Unwind_RaiseException_Phase2 >> has a r70 for clang but not for powerpc64-gcc. >> Or the other way around for __deregister_frame_info_bases >> and _Unwind_Find_FDE. >>=20 >> Which file's implementations are used from >> what I can tell : >>=20 >> uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c >> _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc >> _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc >> _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc >> _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc >> _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc >> _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc >> __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c >> _Unwind_Find_FDE: /usr/src/contrib/gcc/unwind-dw2-fde*.c = (unsure) >>=20 >> An implication is that GPL Version 2 source code >> is involved even when clang is the system compiler. >> Is that what FreeBSD intends for the powerpc >> families? >>=20 >> /* Exception handling and frame unwind runtime interface routines. = -*- C -*- >> Copyright (C) 2001, 2003 Free Software Foundation, Inc. >>=20 >> This file is part of GCC. >>=20 >> GCC is free software; you can redistribute it and/or modify it >> under the terms of the GNU General Public License as published by >> the Free Software Foundation; either version 2, or (at your option) >> any later version. >>=20 >> In addition to the permissions in the GNU General Public License, = the >> Free Software Foundation gives you unlimited permission to link the >> compiled version of this file into combinations with other programs, >> and to distribute those combinations without any restriction coming >> from the use of this file. (The General Public License restrictions >> do apply in other respects; for example, they cover modification of >> the file, and distribution when not linked into a combined >> executable.) >>=20 >> . . . >>=20 >> Does libgcc_s.so.1 with its type of use form a "combined executable"? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Oct 8 23:06:20 2017 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 67422E422A2 for ; Sun, 8 Oct 2017 23:06:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 BDDA76433A for ; Sun, 8 Oct 2017 23:06:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25215 invoked from network); 8 Oct 2017 23:06:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 23:06:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 19:06:17 -0400 (EDT) Received: (qmail 5584 invoked from network); 8 Oct 2017 23:06:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 23:06:17 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 84A37EC7D4D; Sun, 8 Oct 2017 16:06:16 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Date: Sun, 8 Oct 2017 16:06:15 -0700 References: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> To: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers , Justin Hibbits , Nathan Whitehorn , Warner Losh In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) 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, 08 Oct 2017 23:06:20 -0000 Another ABI variation/violation. I top post them because it is largely separate from the AltiVec Registers issue and is probably more important. Summary: Lack of r2-r6 save/restore (and so its matching DW_CFA_ material) so lack of places for the like of _Unwind_SetGR to work with. More detail: Beyond the AltiVec Registers issue it turns out that for: _Unwind_RaiseException _Unwind_ForcedUnwind _Unwind_Resume _Unwind_Resume_or_Rethrow the code generation from clang 5 for them does not save/restore the ABI's "scratch registers" involved in the exception handling: r2-r6. But they are in the code from powerpc64-gcc. In FreeBSD's libgcc_s.so.1 and libcxxrt.so.1 terms: This means that _Unwind_SetGR and _Unwind_GetGR have no place to set or access the value of the r2-r6 GR in question. It currently crashes as the first attempt, which happens to be for setting r3 (as a scratch value). This in turn prevents __gxx_personality_v0 from working. That in turn prevents throwing exceptions from working. Without the code generation, it makes sense to not have the DW_CFA_'s as well. The code generation (or lack of it) is a bigger deal. It appears that in this area clang 5 simply does not currently match the ABI that powerpc64-gcc is generating code for and that FreeBSD's libgcc_s.so.1 and libcxxrt.so.1 are designed for. That is why throwing a C++ exception gets the failure at: Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 context=3D0xffffffffffffcc70) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50042060,= context=3D0xffffffffffffcc70) at unwind.inc:66 #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D terms): In libgcc_s.so.1.full (via clang): uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_RaiseException_Phase2: r70 _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] __deregister_frame_info_bases: (nothing special matched) _Unwind_Find_FDE: (nothing special matched) By contrast for powerpc64-gcc: In libgcc_s.so.1.full (via powerpc64-gcc): uw_update_context_1: r70 _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_RaiseException_Phase2: (nothing special matched) _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 __deregister_frame_info_bases: r70 _Unwind_Find_FDE: r70 On 2017-Oct-8, at 2:24 PM, Mark Millard wrote: > Quick top note: clang 5 does generate code sequences > with AltiVec stvx and lvx instructions where r97-r108 > are listed but powerpc64-gcc is not doing so in those > same sorts of places. This appears to be a ABI > variation across toolchains to me, unless such is > fully optional in the ABI somehow. >=20 > On 2017-Oct-8, at 6:34 AM, Mark Millard = wrote: >=20 >> [Looks like r97-r108 are for vr20-vr31 (AltiVec >> Registers).] >>=20 >> On 2017-Oct-8, at 4:34 AM, Mark Millard = wrote: >>=20 >>> =46rom a dwarfdump's _Unwind_RaiseException information >>> from a clang/clang++ 5 based compile: >>>=20 >>> 91 DW_CFA_offset_extended r97 -496 (62 * -8) >>> 94 DW_CFA_offset_extended r98 -480 (60 * -8) >>> 97 DW_CFA_offset_extended r99 -464 (58 * -8) >>> 100 DW_CFA_offset_extended r100 -448 (56 * -8) >>> 103 DW_CFA_offset_extended r101 -432 (54 * -8) >>> 106 DW_CFA_offset_extended r102 -416 (52 * -8) >>> 109 DW_CFA_offset_extended r103 -400 (50 * -8) >>> 112 DW_CFA_offset_extended r104 -384 (48 * -8) >>> 115 DW_CFA_offset_extended r105 -368 (46 * -8) >>> 118 DW_CFA_offset_extended r106 -352 (44 * -8) >>> 121 DW_CFA_offset_extended r107 -336 (42 * -8) >>> 124 DW_CFA_offset_extended r108 -320 (40 * -8) >>>=20 >>> By contrast devel/powerpc64-gcc does not produce any >>> of those. Is this lack of support of some part of an >>> ABI? Is clang going outside the range of the intended >>> ABI? >>=20 >> ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates >> that r97-r108 are for vr20-vr31 (AltiVec Registers). >> [Is AltiVec optional --possibly missing?] >>=20 >> So the questions translate into questions about >> AltiVec support/handling for C++ exceptions. >>=20 >> [Note: R70 is supposed to be specific to CR2.] >>=20 >>> Does FreeBSD's libgcc_s design and implementation handle >>> these additional logical registers? >> . . . >>=20 >> So the libgcc_s question traces back to: does it >> handle AltiVec Registers vr20-vr31 if they are >> referenced (clang)? Is it well behaved if r97-r108 >> are not referenced (powerpc64-gcc)? >>=20 >>> Supporting notes: >>>=20 >>> r46-r63 are for floating point registers (that >>> have been around for a long time: older >>> powerpc family members). >>=20 >> r46-r63 are for f14-f31. >>=20 >>> r70 is for having/using the value from "mfcr". >>=20 >> Apparently r70 is supposed to be specific to CR2. >>=20 >>> r2(?)-r6 are scratch for C++ exception handling. >>> (I originally identified r3-r6. r2 might have a >>> somewhat distinct status?) >>=20 >> In normal functions r2-r6 do not get >> DW_CFA_offset_extended_sf or >> DW_CFA_offset entries. They are special >> to some internal exception handling >> routines. (See later.) >>=20 >>> r14-r31 are for the normal r14 through r31 >>> registers. >>=20 >> r97-r108 are for AltiVec Registers vr20-vr31. >>=20 >>> r65 is standard and heavily used on all(?) >>> routines, not just some libgcc_s ones. (So >>> r65 is not listed below.) >>=20 >> r65 for lr. >>=20 >>> In libgcc_s.so.1.full (via powerpc64-gcc): >>>=20 >>> uw_update_context_1: r70 >>> _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_RaiseException_Phase2: (nothing special matched) >>> _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 >>> __deregister_frame_info_bases: r70 >>> _Unwind_Find_FDE: r70 >>=20 >> So no AltiVec Registers listed. >>=20 >>> In libgcc_s.so.1.full (via clang): >>>=20 >>> uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) >>> _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_RaiseException_Phase2: r70 >>> _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> __deregister_frame_info_bases: (nothing special matched) >>> _Unwind_Find_FDE: (nothing special matched) >>=20 >> So no internal, special-for-excpetion-routines >> scratch register usage listed (r2-r6). >>=20 >>> clang is missing all the r[2-6] references but >>> the code generated does have the registers in >>> use. Thrown C++ exceptions crash because of >>> the lack of the r2-r6's, dying on a r3 attempt. >>>=20 >> . . . >>>=20 >>> I have no clue why _Unwind_RaiseException_Phase2 >>> has a r70 for clang but not for powerpc64-gcc. >>> Or the other way around for __deregister_frame_info_bases >>> and _Unwind_Find_FDE. >>>=20 >>> Which file's implementations are used from >>> what I can tell : >>>=20 >>> uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c >>> _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc >>> __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c >>> _Unwind_Find_FDE: = /usr/src/contrib/gcc/unwind-dw2-fde*.c (unsure) >>>=20 >>> An implication is that GPL Version 2 source code >>> is involved even when clang is the system compiler. >>> Is that what FreeBSD intends for the powerpc >>> families? >>>=20 >>> /* Exception handling and frame unwind runtime interface routines. = -*- C -*- >>> Copyright (C) 2001, 2003 Free Software Foundation, Inc. >>>=20 >>> This file is part of GCC. >>>=20 >>> GCC is free software; you can redistribute it and/or modify it >>> under the terms of the GNU General Public License as published by >>> the Free Software Foundation; either version 2, or (at your option) >>> any later version. >>>=20 >>> In addition to the permissions in the GNU General Public License, = the >>> Free Software Foundation gives you unlimited permission to link the >>> compiled version of this file into combinations with other programs, >>> and to distribute those combinations without any restriction coming >>> from the use of this file. (The General Public License restrictions >>> do apply in other respects; for example, they cover modification of >>> the file, and distribution when not linked into a combined >>> executable.) >>>=20 >>> . . . >>>=20 >>> Does libgcc_s.so.1 with its type of use form a "combined = executable"? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Oct 9 21:17:56 2017 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 10FC4E3C500 for ; Mon, 9 Oct 2017 21:17:56 +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 F2F8280617 for ; Mon, 9 Oct 2017 21:17:55 +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 v99LHte2036700 for ; Mon, 9 Oct 2017 21:17:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 222858] Clang doesn't find and libomp.so when compiling with -fopenmp Date: Mon, 09 Oct 2017 21:17:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People 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, 09 Oct 2017 21:17:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222858 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 Wed Oct 11 02:43:17 2017 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 394F4E441E5 for ; Wed, 11 Oct 2017 02:43:17 +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 2584D76084 for ; Wed, 11 Oct 2017 02:43:17 +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 v9B2hGfG030434 for ; Wed, 11 Oct 2017 02:43:17 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: Wed, 11 Oct 2017 02:43:17 +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: jhibbits@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc 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: Wed, 11 Oct 2017 02:43:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |jhibbits@FreeBSD.org Resolution|--- |DUPLICATE --- Comment #1 from Justin Hibbits --- *** This bug has been marked as a duplicate of bug 220122 *** --=20 You are receiving this mail because: You are the assignee for the bug.=