From owner-freebsd-ppc@freebsd.org Sun Oct 8 03:33:09 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3DCEE248F0 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 1583A68A81 for ; Sun, 8 Oct 2017 03:33:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 631 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 03:33:09 -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-ppc@freebsd.org Sun Oct 8 02:38:49 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A76F7E48FE3 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 D122C81A18 for ; Sun, 8 Oct 2017 02:38:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32075 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-ppc@freebsd.org Sun Oct 8 04:46:06 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DA3DE266F4 for ; Sun, 8 Oct 2017 04:46:06 +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 84BE97C326 for ; Sun, 8 Oct 2017 04:46:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15041 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-ppc@freebsd.org Sun Oct 8 11:34:38 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A22EE323DC 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 BC6BA6F818 for ; Sun, 8 Oct 2017 11:34:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1418 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-ppc@freebsd.org Sun Oct 8 13:34:49 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB93DE35BE6 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 386D16977C for ; Sun, 8 Oct 2017 13:34:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19425 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 13:34:50 -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-ppc@freebsd.org Sun Oct 8 20:01:38 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DE13E3EA53 for ; Sun, 8 Oct 2017 20:01:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1887C82057 for ; Sun, 8 Oct 2017 20:01:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 91959AF55; Sun, 8 Oct 2017 20:01:08 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 78B43AF52 for ; Sun, 8 Oct 2017 20:01:08 +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 1A77381DA6 for ; Sun, 8 Oct 2017 20:01:07 +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 v98K16Of071717 for ; Sun, 8 Oct 2017 20:01:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 222799] net-p2p/libtorrent: Patch for fix building on powerpc arch Date: Sun, 08 Oct 2017 20:01:06 +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 Some People X-Bugzilla-Who: dbaio@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: short_desc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 20:01:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222799 Danilo G. Baio changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|patch for fix building |net-p2p/libtorrent: Patch |net-p2p/rorrent on powerpc |for fix building on powerpc |arch |arch Status|New |Open --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Oct 8 21:24:11 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7CD6E40764 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 356406F4B8 for ; Sun, 8 Oct 2017 21:24:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4994 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 21:24:11 -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-ppc@freebsd.org Sun Oct 8 23:06:20 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 874B1E422A3 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 D67CC6433F for ; Sun, 8 Oct 2017 23:06:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5117 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-ppc@freebsd.org Mon Oct 9 09:44:17 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3119E2B454 for ; Mon, 9 Oct 2017 09:44:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A8D96D81F for ; Mon, 9 Oct 2017 09:44:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id C5F0C1656B; Mon, 9 Oct 2017 09:43:35 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id AE7DC16566 for ; Mon, 9 Oct 2017 09:43:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93D206D5F8 for ; Mon, 9 Oct 2017 09:43:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v999hVma031696 for ; Mon, 9 Oct 2017 09:43:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 222799] net-p2p/libtorrent: Patch for fix building on powerpc arch Date: Mon, 09 Oct 2017 09:43:32 +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 Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 09:44:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222799 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: danfe Date: Mon Oct 9 09:42:45 UTC 2017 New revision: 451589 URL: https://svnweb.freebsd.org/changeset/ports/451589 Log: Disable instrumentation on 32-bit PowerPC like we already do for i386/gcc to avoid linking errors (e.g., when building dependent `net-p2p/rtorrent' port) and update the comment accordingly. PR: 222799 (modified) Changes: head/net-p2p/libtorrent/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Oct 9 09:46:15 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6638E2B509 for ; Mon, 9 Oct 2017 09:46:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 386F16E02C for ; Mon, 9 Oct 2017 09:46:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 2D970170B8; Mon, 9 Oct 2017 09:45:54 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 19A2D170B5 for ; Mon, 9 Oct 2017 09:45:54 +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 29CAE6DEA7 for ; Mon, 9 Oct 2017 09:45:53 +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 v999jqg1035250 for ; Mon, 9 Oct 2017 09:45:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 222799] net-p2p/libtorrent: Patch for fix building on powerpc arch Date: Mon, 09 Oct 2017 09:45:53 +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 Some People X-Bugzilla-Who: danfe@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 09:46:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222799 Alexey Dokuchaev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danfe@FreeBSD.org Status|Open |Closed Resolution|--- |FIXED --- Comment #2 from Alexey Dokuchaev --- Committed as ports r451589 (unrelated changes omitted), thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Thu Oct 12 19:03:36 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F020E3224D for ; Thu, 12 Oct 2017 19:03:36 +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 4CD5263A07 for ; Thu, 12 Oct 2017 19:03:36 +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 v9CJ3aZE055234 for ; Thu, 12 Oct 2017 19:03:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 181502] /usr/include/stdint.h 9.2-RC1/powerpc does not compile on powerpc32 Date: Thu, 12 Oct 2017 19:03:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: powerpc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 19:03:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181502 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |jhibbits@FreeBSD.org Status|In Progress |Closed --- Comment #4 from Justin Hibbits --- No new updates in 3 years, so closing as fixed by Andreas. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Fri Oct 13 03:49:33 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13818E3BE91 for ; Fri, 13 Oct 2017 03:49:33 +0000 (UTC) (envelope-from swp04@mathistry.net) Received: from pacmmta56.windstream.net (pacmmta56-sus.windstream.net [162.39.147.247]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C021D724B2 for ; Fri, 13 Oct 2017 03:49:31 +0000 (UTC) (envelope-from swp04@mathistry.net) Received: from beryllium.local ([98.21.51.179]) by pacmmta56.windstream.net with pacmmta56 id LroP1w00A3ryqQa01roPqc; Thu, 12 Oct 2017 23:48:23 -0400 X-WS-COS: WSOB803 X-Cloudmark-Category: undefined X-Cloudmark-Analysis: v=2.2 cv=Fo/qxyjq c=1 sm=1 tr=0 a=vg5yxnLjwFr4UNCaeqU3QA==:117 a=vg5yxnLjwFr4UNCaeqU3QA==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=a7_CA6RWC-ZUH38yb2QA:9 a=QEXdDO2ut3YA:10 X-Cloudmark-Score: 0.00 X-WS-AID: OTguMjEuNTEuMTc5 Received: from [192.168.1.36] (krypton.local [192.168.1.36]) by beryllium.local (8.15.2/8.15.2) with ESMTP id v9D3mNtw019815; Thu, 12 Oct 2017 23:48:23 -0400 (EDT) (envelope-from swp04@mathistry.net) To: freebsd-ports@freebsd.org, freebsd-ppc@freebsd.org From: Steve Peurifoy Subject: Build failure of gobject-introspection on ppc32 Message-ID: Date: Thu, 12 Oct 2017 23:48:23 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 03:49:33 -0000 On attempting to build x11-wm/xfce4 on an ibook G4 running 11.1-RELEASE with a ports tree updated on 2017/10/04, I encountered a failure indevel/gobject-introspection: ERROR: Failed to re-parse gir file; scanned='/tmp/tmpASp2z3.gir' passthrough='/tmp/tmpMHZdPr.gir' gmake[3]: *** [Makefile:3521: Gio-2.0.gir] Error 1 gmake[3]: Leaving directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.50.0' gmake[2]: *** [Makefile:2810: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.50.0' gmake[1]: *** [Makefile:1570: all] Error 2 gmake[1]: Leaving directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-1.50.0' ===> Compilation failed unexpectedly. Rifling through the source at giscanner/scannermain.py, one finds that the failure stems from a simple comparison of the two named files and that they do in fact differ in one line (out of ~92,000): *** tmpASp2z3.gir Wed Oct 11 23:24:40 2017 --- tmpMHZdPr.gir Wed Oct 11 23:24:41 2017 *************** *** 45286,45292 **** the new #GIOExtensionPoint. This object is owned by GIO and should not be freed. ! --- 45286,45292 ---- the new #GIOExtensionPoint. This object is owned by GIO and should not be freed. ! The line in the "passthrough" file appears to have a 20 byte blob of alien substring from elsewhere in the file dropped into it. Curiously, the final character of that substring is at offset 0x1fffff in the file. I could be wrong, but I'm having a hard time believing that that's just a coincidence. This is repeatable. Is this port known to be broken on ppc32? Any advice on how best to track it down? My knowledge of python is thus far inadequate to decipher what the function that generates the passthrough file is doing, so I'll have to work on that. I'm not sure the problem isn't at a lower level though. Thanks, -Steve From owner-freebsd-ppc@freebsd.org Sat Oct 14 04:20:26 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D15AAE3BB82; Sat, 14 Oct 2017 04:20:26 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96A242B90; Sat, 14 Oct 2017 04:20:26 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id t203so5253836vke.0; Fri, 13 Oct 2017 21:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JLm0NIy3T8ldzNj56HhWnMl3aoWmOksWZ5sXXfvLKQo=; b=pmiiNku/AXC7YM0NU9crysTej/nQK3MNW/FhbRkdYjiuSVUAxfySfohEf68YupDLYJ Qw7vzDW1JKFBMFdDLmC3bk+V2rPYNRKI2NqP1vwQTOD1nIAb/r90BbaNk7XDeBYmsHG3 1lNMj7mPVgEBpjOxzgbjzPERA7+5IrAt9OGd+79/jNkio9NMDtrOiygAFvDYPjQXkOuY HZC3aNV2LyrnAWk3L8XFAhrduAiOThvgo81aeR8TOQnrA4zj4PVh4zLjN+zTF17n3WnE TbDp8iQKAHYaBSDjdpshKV3wmCAEQ7dF5yp+giIez4hwcONmK6pk9w7lpa+RwkpVz3pr Qzkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JLm0NIy3T8ldzNj56HhWnMl3aoWmOksWZ5sXXfvLKQo=; b=VUlclSA5bHEFBOnCyspSrGAu2FotkWe+Et062/5GkwVn8nIJ8wVDWrKIFrlSsp0SZR +extqTkJdiLYX7Ecc7JsOg8z+wZ4vdJw1R11BGcI35vJQqP4xUI+EKyltSmboFUtNjf5 xjfsWQ2cOAch2W2J9yZn9+3xYfPo6+b8Zb4aNzWwrByDXyIwyoybXu8bR5OhrN9v/Gsv 3pwqlb4JCf4WK8FCSQcuMvLh4LgXyOdc/j3xcOhU2nCIGgq9KqZKIrq7jJOnalPKOfb5 0IENpkZtpMQcRvhDi6N+XVzFRSIP+5OnSxGXv5yTumdyen1/h2mEfrPgznoZGakfiZIa d0UQ== X-Gm-Message-State: AMCzsaXVLYVJ5cPhcfUPMHdL6MDHwd9wi13aOlun6zRPlpi+X3bznGJm 2GXVHeUdiRG9WWOpY4udZSLT2PGZMeygU8DF/cdIHQ== X-Google-Smtp-Source: AOwi7QDh7do9DKxkiwcyURmoxDfWQ6MQXtm/KYBjixQpJiXHA1yOYD96emMvbNhLD/pdjgxjaqwJ8m9aMQqMdwkKP68= X-Received: by 10.31.166.66 with SMTP id p63mr2580360vke.42.1507954825267; Fri, 13 Oct 2017 21:20:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.50.129 with HTTP; Fri, 13 Oct 2017 21:19:44 -0700 (PDT) In-Reply-To: <20171014034936.GA18066@lonesome.com> References: <20171014034936.GA18066@lonesome.com> From: grarpamp Date: Sat, 14 Oct 2017 00:19:44 -0400 Message-ID: Subject: Re: Power9 Inexpensive Development Testbed To: freebsd-ppc@freebsd.org Cc: freebsd-riscv@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 04:20:26 -0000 On Fri, Oct 13, 2017 at 11:49 PM, Mark Linimon wrote: > A few of us FreeBSD/powerpc64 fans are watching the developments > closely. Meant to copy the above on the info, was going wider with it since a lot of people these days are talking about alternatives to the issues of closed hardware blobs and may not know of any relatively more open platforms. What is "the" mail list[s] / forum for the power9 / power8 user / dev community? Here is the link to the collated bits so far... http://docs.freebsd.org/cgi/mid.cgi?CAD2Ti29pAzag6eGoxRnSw1tSmd-hk2XAxak4huVusi+poMEmFQ