From owner-freebsd-toolchain@freebsd.org Tue Sep 5 20:01:09 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5688E1C64E for ; Tue, 5 Sep 2017 20:01:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 41C9B7E20D for ; Tue, 5 Sep 2017 20:01:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10249 invoked from network); 5 Sep 2017 19:59:47 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 19:59:47 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 15:54:28 -0400 (EDT) Received: (qmail 8028 invoked from network); 5 Sep 2017 19:54:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 19:54:27 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id EFF64EC94DA; Tue, 5 Sep 2017 12:54:26 -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: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like Message-Id: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084@dsl-only.net> Date: Tue, 5 Sep 2017 12:54:26 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:01:09 -0000 In an experiment with building some arm ports via poudriere cross building on amd64 I got the following. It appears that clang does not handle all the assembler notation and a different assembler might need to be used for x11/pixman . (The x11/pixman usage is indirect from having specified x11/lumina and x11/xscreensaver ). --- pixman-arm-simd-asm.lo --- /bin/sh ../libtool --mode=3Dcompile /nxb-bin/usr/bin/cc = -DHAVE_CONFIG_H -I. -I.. -mcpu=3Dcortex-a7 -O2 -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo = -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo = pixman-arm-simd-asm.S libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. = -mcpu=3Dcortex-a7 -O2 -pipe -mcpu=3Dcortex-a7 -g -fno-strict-aliasing = -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c = pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o :1:1: error: unknown directive . . . --- pixman-arm-simd-asm.lo --- .func fname ^ ./pixman-arm-simd-asm.h:599:5: note: while in macro instantiation pixman_asm_function fname ^ /tmp/pixman-arm-simd-asm-b59328.s:910:1: note: while in macro = instantiation generate_composite_function pixman_composite_src_8888_8888_asm_armv6, = 32, 0, 32, FLAG_DST_WRITEONLY | FLAG_COND_EXEC | = FLAG_SPILL_LINE_VARS_WIDE | FLAG_PROCESS_PRESERVES_SCRATCH, 4, = blit_init, nop_macro, nop_macro, blit_process_head, nop_macro, = blit_inner_loop ^ ./pixman-arm-simd-asm.h:614:6: error: expected absolute expression .if prefetch_distance =3D=3D 0 ^ /tmp/pixman-arm-simd-asm-b59328.s:910:1: note: while in macro = instantiation generate_composite_function pixman_composite_src_8888_8888_asm_armv6, = 32, 0, 32, FLAG_DST_WRITEONLY | FLAG_COND_EXEC | = FLAG_SPILL_LINE_VARS_WIDE | FLAG_PROCESS_PRESERVES_SCRATCH, 4, = blit_init, nop_macro, nop_macro, blit_process_head, nop_macro, = blit_inner_loop ^ ./pixman-arm-simd-asm.h:620:6: error: expected absolute expression .if src_bpp =3D=3D 32 ^ . . . (I've omitted much later material continuing to reject notation.) (A variant build without the -mcpu=3Dcortex-a7 usage got the same.) The context for the above is from a poudriere/qemu-user-static/native_xtools based cross build from amd64: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt The -x use was enabled for -m null via: /usr/local/share/poudriere/jail.sh having a "build_native_xtools" added: null) JAILFS=3Dnone FCT=3Dbuild_native_xtools ;; # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323147M amd64 = amd64 1200043 1200043 /usr/obj/DESTDIRs/clang-armv7-installworld-poud is from an arm/armv6 build of the same sources using -mcpu=3Dcortex-a7 , installed via installworld distrib-dirs distribution DB_FROM_SRC=3D1 DESTDIR=3D. . . : # more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. The source variations are almost all for powerpc family explorations: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/Makefile M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/boot1.chrp/Makefile M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 449165 Last Changed Rev: 449165 # svnlite status /usr/ports/ | sort M /usr/ports/Mk/bsd.port.mk M /usr/ports/base/gcc/Makefile M /usr/ports/base/gcc/distinfo M /usr/ports/base/gcc/pkg-plist M /usr/ports/devel/libunwind/Makefile M /usr/ports/sysutils/cdrdao/Makefile # more /usr/local/etc/poudriere.d/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif MALLOC_PRODUCTION=3D # more /usr/local/etc/poudriere.d/zrFBSDx64CjailArmV7-make.conf = = =20 CFLAGS+=3D -mcpu=3Dcortex-a7 CXXFLAGS+=3D -mcpu=3Dcortex-a7 CPPFLAGS+=3D -mcpu=3Dcortex-a7 As for that "ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG" I have in /usr/ports/Mk/bsd.port.mk : STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif I've also had trouble in some contexts with where bad.port.mk uses ${UNAME} (empty string results) and so have forced the expected content to match the context that this is in: # Get the architecture .if !defined(ARCH) -ARCH!=3D ${UNAME} -p +ARCH!=3D echo amd64 .endif _EXPORTED_VARS+=3D ARCH =20 # Get the operating system type .if !defined(OPSYS) -OPSYS!=3D ${UNAME} -s +OPSYS!=3D echo FreeBSD .endif _EXPORTED_VARS+=3D OPSYS =20 .if !defined(_OSRELEASE) -_OSRELEASE!=3D ${UNAME} -r +_OSRELEASE!=3D echo 12.0-CURRENT .endif _EXPORTED_VARS+=3D _OSRELEASE =20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Sep 5 20:13:15 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 344D1E1CF11; Tue, 5 Sep 2017 20:13:15 +0000 (UTC) (envelope-from jbeich@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 D1C0C80DEC; Tue, 5 Sep 2017 20:13:14 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 8CFB41DF04; Tue, 5 Sep 2017 20:13:11 +0000 (UTC) From: Jan Beich To: Mark Millard Cc: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports , FreeBSD Toolchain Subject: Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like References: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> Date: Tue, 05 Sep 2017 22:13:05 +0200 In-Reply-To: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> (Mark Millard's message of "Tue, 5 Sep 2017 12:54:26 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:13:15 -0000 Mark Millard writes: > In an experiment with building some arm ports via poudriere > cross building on amd64 I got the following. It appears that > clang does not handle all the assembler notation and a > different assembler might need to be used for x11/pixman . > (The x11/pixman usage is indirect from having specified > x11/lumina and x11/xscreensaver ). > > --- pixman-arm-simd-asm.lo --- > /bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo pixman-arm-simd-asm.S > libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o > :1:1: error: unknown directive > . . . > --- pixman-arm-simd-asm.lo --- > .func fname > ^ Does it still happen after https://svnweb.freebsd.org/changeset/ports/449285 ? From owner-freebsd-toolchain@freebsd.org Tue Sep 5 20:33:10 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FF04E1DDD5 for ; Tue, 5 Sep 2017 20:33:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 6FB3D180A for ; Tue, 5 Sep 2017 20:33:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13518 invoked from network); 5 Sep 2017 20:38:27 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 20:38:27 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 16:33:07 -0400 (EDT) Received: (qmail 1764 invoked from network); 5 Sep 2017 20:33:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 20:33:07 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 818F8EC807E; Tue, 5 Sep 2017 13:33:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like From: Mark Millard In-Reply-To: Date: Tue, 5 Sep 2017 13:33:05 -0700 Cc: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8A60350E-0D95-4D47-A7E8-6AF1A7727A93@dsl-only.net> References: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> To: Jan Beich X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:33:10 -0000 On 2017-Sep-5, at 1:13 PM, Jan Beich wrote: > Mark Millard writes: >=20 >> In an experiment with building some arm ports via poudriere >> cross building on amd64 I got the following. It appears that >> clang does not handle all the assembler notation and a >> different assembler might need to be used for x11/pixman . >> (The x11/pixman usage is indirect from having specified >> x11/lumina and x11/xscreensaver ). >>=20 >> --- pixman-arm-simd-asm.lo --- >> /bin/sh ../libtool --mode=3Dcompile /nxb-bin/usr/bin/cc = -DHAVE_CONFIG_H -I. -I.. -mcpu=3Dcortex-a7 -O2 -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo = -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo = pixman-arm-simd-asm.S >> libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. = -mcpu=3Dcortex-a7 -O2 -pipe -mcpu=3Dcortex-a7 -g -fno-strict-aliasing = -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c = pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o >> :1:1: error: unknown directive >> . . . >> --- pixman-arm-simd-asm.lo --- >> .func fname >> ^ >=20 > Does it still happen after = https://svnweb.freebsd.org/changeset/ports/449285 ? I'll let you know. But it will be a while for the results: I just started another build experiment with: poudriere bulk -j zrFBSDx64CjailArmV7 -w -c -f ~/armv7-origins.txt This is based on /usr/ports having -r449313 . (I updated based on your question.) It will likely take 2-4 hours to get that far in the 338 packages it is attempting to build. (I'm more experimenting with building than using the results currently. Previously my port builds were all native and via portmaster .) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Sep 5 21:38:46 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C514AE20737 for ; Tue, 5 Sep 2017 21:38:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 CBF807004C for ; Tue, 5 Sep 2017 21:38:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19560 invoked from network); 5 Sep 2017 21:38:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 21:38:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 17:38:43 -0400 (EDT) Received: (qmail 1499 invoked from network); 5 Sep 2017 21:38:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 21:38:43 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9A5C0EC807E; Tue, 5 Sep 2017 14:38:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like From: Mark Millard In-Reply-To: <8A60350E-0D95-4D47-A7E8-6AF1A7727A93@dsl-only.net> Date: Tue, 5 Sep 2017 14:38:41 -0700 Cc: freebsd-arm , FreeBSD Toolchain , x11@FreeBSD.org, FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: <3354A557-4707-40C1-916F-6E0C066A7A80@dsl-only.net> References: <5CAB42C9-984A-4BC9-A4CC-4BDD74932084__24380.8804465973$1504641758$gmane$org@dsl-only.net> <8A60350E-0D95-4D47-A7E8-6AF1A7727A93@dsl-only.net> To: Jan Beich X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:38:47 -0000 On 2017-Sep-5, at 1:33 PM, Mark Millard wrote: > On 2017-Sep-5, at 1:13 PM, Jan Beich wrote: >=20 >> Mark Millard writes: >>=20 >>> In an experiment with building some arm ports via poudriere >>> cross building on amd64 I got the following. It appears that >>> clang does not handle all the assembler notation and a >>> different assembler might need to be used for x11/pixman . >>> (The x11/pixman usage is indirect from having specified >>> x11/lumina and x11/xscreensaver ). >>>=20 >>> --- pixman-arm-simd-asm.lo --- >>> /bin/sh ../libtool --mode=3Dcompile /nxb-bin/usr/bin/cc = -DHAVE_CONFIG_H -I. -I.. -mcpu=3Dcortex-a7 -O2 -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo = -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo = pixman-arm-simd-asm.S >>> libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. = -mcpu=3Dcortex-a7 -O2 -pipe -mcpu=3Dcortex-a7 -g -fno-strict-aliasing = -MT pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c = pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o >>> :1:1: error: unknown directive >>> . . . >>> --- pixman-arm-simd-asm.lo --- >>> .func fname >>> ^ >>=20 >> Does it still happen after = https://svnweb.freebsd.org/changeset/ports/449285 ? >=20 > . . . > This is based on /usr/ports having -r449313 . (I updated based on > your question.) > . . . The rebuild of the ports rebuilt x11/pixman earlier in the sequence than I had guessed so it took less time to get to that point: [00:51:26] [03] [00:00:00] Building x11/pixman | pixman-0.34.0 . . . [00:54:15] [03] [00:02:49] Finished x11/pixman | pixman-0.34.0: Success So -r449285 has avoided using clang's internal assembler. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Sep 5 23:38:37 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A74AAE02422 for ; Tue, 5 Sep 2017 23:38:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 4F3D669991 for ; Tue, 5 Sep 2017 23:38:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1508 invoked from network); 5 Sep 2017 23:40:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Sep 2017 23:40:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Tue, 05 Sep 2017 19:38:34 -0400 (EDT) Received: (qmail 799 invoked from network); 5 Sep 2017 23:38:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Sep 2017 23:38:34 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 896F3EC807E; Tue, 5 Sep 2017 16:38:33 -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: x11-toolkits/qt5-gui vs. arm.armv6 build via poudriere cross build: fails (undefined references) and odd mix of "clang++" vs. "/nxb-bin/usr/bin/c++" Message-Id: <4142F136-53C5-40CF-8B0A-BE68BC9EBFC6@dsl-only.net> Date: Tue, 5 Sep 2017 16:38:32 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , x11@FreeBSD.org, FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:38:37 -0000 This is a bit odd so I give it in stages. The context is based on: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt (More details given later.) First there is some unexpected use of (for example) clang++ instead of /nxb-bin/usr/bin/c++ . Then later I show some undefined references that make the build fail. For the clang++ vs. /nxb-bin/usr/bin/c++ there was (for example): --CONFIGURE_ENV-- = QMAKESPEC=3D"/usr/local/lib/qt5/mkspecs/freebsd-$(ccver=3D"$(/nxb-bin/usr/= bin/c++ --version)"; case "$ccver" in *clang*) echo clang ;; *) echo g++ = ;; esac)" MAKE=3D"make" QT_SELECT=3Dqt5 PKG_CONFIG=3Dpkgconf = XDG_DATA_HOME=3D/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work = XDG_CONFIG_HOME=3D/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work = HOME=3D/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work TMPDIR=3D"/tmp" = SHELL=3D/bin/sh CONFIG_SHELL=3D/bin/sh --End CONFIGURE_ENV-- Note the expected use of /nxb-bin/usr/bin/c++ . There is also the later: ---Begin make.nxb.conf--- CC=3D/nxb-bin/usr/bin/cc CPP=3D/nxb-bin/usr/bin/cpp CXX=3D/nxb-bin/usr/bin/c++ AS=3D/nxb-bin/usr/bin/as NM=3D/nxb-bin/usr/bin/nm LD=3D/nxb-bin/usr/bin/ld OBJCOPY=3D/nxb-bin/usr/bin/objcopy SIZE=3D/nxb-bin/usr/bin/size STRIPBIN=3D/nxb-bin/usr/bin/strip SED=3D/nxb-bin/usr/bin/sed READELF=3D/nxb-bin/usr/bin/readelf RANLIB=3D/nxb-bin/usr/bin/ranlib YACC=3D/nxb-bin/usr/bin/yacc MAKE=3D/nxb-bin/usr/bin/make STRINGS=3D/nxb-bin/usr/bin/strings AWK=3D/nxb-bin/usr/bin/awk FLEX=3D/nxb-bin/usr/bin/flex ---End make.nxb.conf--- Yet for some reason x11-toolkits/qt5-gui reports using clang++ commands in config activity instead. For example: Running configuration tests... Determining architecture... () clang++ -c -pipe -g -Wall -W -fPIC -I. -I/usr/local/include = -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o arch.o arch.cpp clang++ -o arch arch.o -L/usr/local/lib Found architecture in binary CFG_ARCH=3D"arm" CFG_CPUFEATURES=3D"" System architecture: 'arm' Host architecture: 'arm' clang++ -c -fvisibility=3Dhidden fvisibility.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this = behavior is deprecated [-Wdeprecated] Symbol visibility control enabled. clang++ -o libtest.so -shared -Wl,-Bsymbolic-functions -fPIC = bsymbolic_functions.c clang++: warning: treating 'c' input as 'c++' when in C++ mode, this = behavior is deprecated [-Wdeprecated] bsymbolic_functions.c:2:2: error: "Symbolic function binding on this = architecture may be broken, disabling it (see QTBUG-36129)." #error "Symbolic function binding on this architecture may be broken, = disabling it (see QTBUG-36129)." ^ 1 error generated. Symbolic function binding disabled. (I omit a lot more such "clang++" lines in the config stages of output. I did not see any /nxb-bin/usr/bin/c++ in that area.) Still it later reports: Configure summary Build type: /usr/local/lib/qt5/mkspecs/freebsd-clang (arm, CPU = features: none detected) qmake vars .......... QMAKE_CC =3D /nxb-bin/usr/bin/cc QMAKE_CXX =3D = /nxb-bin/usr/bin/c++ . . . It later uses the /nxb-bin/usr/bin/c* commands in the actual build. As for the build failure itself. . . --- ../../lib/libQt5Gui.so.5.7.1 --- rm -f libQt5Gui.so.5.7.1 libQt5Gui.so libQt5Gui.so.5 libQt5Gui.so.5.7 /nxb-bin/usr/bin/c++ -Wl,--as-needed -Wl,--no-undefined = -Wl,--version-script,QtGui.version -Wl,--enable-new-dtags -pthread = -Wl,-rpath,/usr/local/lib/qt5 -shared -Wl,-soname,libQt5Gui.so.5 -o = libQt5Gui.so.5.7.1 .obj/qaccessible.o . . . fails with: .obj/qimage.o: In function `_ZL10qt_memfillIjEvPT_S0_i': = /wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/s= rc/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/pain= ting/qdrawhelper_p.h:803: undefined reference to `qt_memfill32(unsigned = int*, unsigned int, int)' = /wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/s= rc/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/pain= ting/qdrawhelper_p.h:803: undefined reference to `qt_memfill32(unsigned = int*, unsigned int, int)' .obj/qimage_conversions.o:(.data+0x524): undefined reference to = `convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, = QFlags)' .obj/qimage_conversions.o:(.data+0x528): undefined reference to = `convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, = QFlags)' .obj/qimage_conversions.o:(.data+0x52c): undefined reference to = `convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, = QFlags)' .obj/qcompositionfunctions.o: In function `_ZL10qt_memfillIjEvPT_S0_i': = /wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/s= rc/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/pain= ting/qdrawhelper_p.h:803: undefined reference to `qt_memfill32(unsigned = int*, unsigned int, int)' . . . (I've omitted a lot more such notices of undefined references.) The context for all the above is from a poudriere/qemu-user-static/native_xtools based cross build from amd64: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt The -x use was enabled for -m null via: /usr/local/share/poudriere/jail.sh having a "build_native_xtools" added: null) JAILFS=3Dnone FCT=3Dbuild_native_xtools ;; # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323147M amd64 = amd64 1200043 1200043 /usr/obj/DESTDIRs/clang-armv7-installworld-poud is from an arm/armv6 build of the same sources using -mcpu=3Dcortex-a7 , installed via installworld distrib-dirs distribution DB_FROM_SRC=3D1 DESTDIR=3D. . . : # more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host=20 TO_TYPE=3Darmv6 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. The source variations are almost all for powerpc family explorations: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/Makefile M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/boot1.chrp/Makefile M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 449313 Last Changed Rev: 449313 # svnlite status /usr/ports/ | sort M /usr/ports/Mk/bsd.port.mk M /usr/ports/base/gcc/Makefile M /usr/ports/base/gcc/distinfo M /usr/ports/base/gcc/pkg-plist M /usr/ports/devel/libunwind/Makefile M /usr/ports/sysutils/cdrdao/Makefile # more /usr/local/etc/poudriere.d/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/webkit-qt5*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif MALLOC_PRODUCTION=3D # more /usr/local/etc/poudriere.d/zrFBSDx64CjailArmV7-make.conf = =20 CFLAGS+=3D -mcpu=3Dcortex-a7 CXXFLAGS+=3D -mcpu=3Dcortex-a7 CPPFLAGS+=3D -mcpu=3Dcortex-a7 As for that "ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG" I have in /usr/ports/Mk/bsd.port.mk : STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif I've also had trouble in some contexts where bad.port.mk uses ${UNAME} (empty string results) and so have forced the expected content to match the context that this is in a couple of the places: # Get the operating system type .if !defined(OPSYS) -OPSYS!=3D ${UNAME} -s +OPSYS!=3D echo FreeBSD .endif _EXPORTED_VARS+=3D OPSYS .if !defined(_OSRELEASE) -_OSRELEASE!=3D ${UNAME} -r +_OSRELEASE!=3D echo 12.0-CURRENT .endif _EXPORTED_VARS+=3D _OSRELEASE =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Sep 6 09:40:40 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D0B7E1D826 for ; Wed, 6 Sep 2017 09:40:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 DB2616A66E for ; Wed, 6 Sep 2017 09:40:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26025 invoked from network); 6 Sep 2017 09:40:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Sep 2017 09:40:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 06 Sep 2017 05:40:37 -0400 (EDT) Received: (qmail 14827 invoked from network); 6 Sep 2017 09:40:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Sep 2017 09:40:37 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id DF7E1EC926D; Wed, 6 Sep 2017 02:40:36 -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: Could someone see about possibly applying the patch(s) from bugzilla 216816 so arm qt5 builds can work? (includes patching bsd.qt.mk) Date: Wed, 6 Sep 2017 02:40:36 -0700 References: Cc: mmel@freebsd.org, mikael.urankar@gmail.com, tcberner@freebsd.org, mi@ALDAN.algebra.com To: FreeBSD Toolchain , freebsd-arm , x11@FreeBSD.org, FreeBSD Ports Message-Id: <4886EB2D-3F85-4DC9-954A-99B874334ADB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:40:40 -0000 The patches mentioned below have been in bugzilla 216816 since 2017-Feb-05 but no one has applied them. The author of the patches reports below having a poudriere build log showing a successful build for x11-toolkits/qt5-gui . (My older bugzilla report 206348 was about qt5-gui specifically.) Could someone see about applying some variation of the patches so arm builds of such things are no longer blocked? FYI: Part of the context here is use of -mcpu=3Dcortex-a7 and the like. > From: bugzilla-noreply@freebsd.org > Subject: [Bug 216816] [PATCH] devel/qt5: In arch.test, use CXXFLAGS = from make environment > Date: September 6, 2017 at 1:31:47 AM PDT > To: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216816 >=20 > --- Comment #8 from Michal Meloun --- > This patch affects many (if not all) of qt5 ports, so you must rebuild = all of > them.=20 > In any case, I can build qt5-gui without problem: > = http://build.humusoft.cz/data/head12armv7-default/2017-03-11_19h10m04s/log= s/qt5-gui-5.7.1.log >=20 > --=20 > You are receiving this mail because: > You are on the CC list for the bug. Note: Bugzilla 206348 and 217278 are also reports of the problem(s), noted as duplicates of the bugzilla that has the patches at this point. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Sep 6 23:54:14 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADF4DE1E0B6 for ; Wed, 6 Sep 2017 23:54:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 1F9AC63E6E for ; Wed, 6 Sep 2017 23:54:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24610 invoked from network); 6 Sep 2017 23:56:06 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Sep 2017 23:56:06 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 06 Sep 2017 19:54:11 -0400 (EDT) Received: (qmail 9555 invoked from network); 6 Sep 2017 23:54:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Sep 2017 23:54:11 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B1C6BEC9274; Wed, 6 Sep 2017 16:54:10 -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/lib/clang/freebsd_cc_version.h , FREEBSD_CC_VERSION : When is it supposed to update? Message-Id: <77543DF5-251C-438E-92A2-06574A687F9F@dsl-only.net> Date: Wed, 6 Sep 2017 16:54:09 -0700 To: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 23:54:14 -0000 When is: head/lib/clang/freebsd_cc_version.h supposed to have: FREEBSD_CC_VERSION updated? Back on 2016-May-23 Bryan Drewery wrote on the lists: > A critical note to toolchain developers, or anyone who touches the = Clang=20 > or GCC source files. If you modify these files or add a new target=20 > architecture into Clang, please bump the revision in the appropriate = file:=20 (It has moved since then.) Does this still apply? The most recent FREEBSD_CC_VERSION update was the clang 4 -> clang 5 = transition: > Revision 321369 - (view) (download) (annotate) - [select for diffs]=20 > Modified Sat Jul 22 11:08:25 2017 UTC (6 weeks, 4 days ago) by dim=20 > File length: 53 byte(s)=20 > Diff to previous 314564 > Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ = to > 5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release, > which should be in about a month. Please report bugs and regressions, > so we can get them into the release. >=20 > Please note that from 3.5.0 onwards, clang, llvm and lldb require = C++11 > support to build; see UPDATING for more information. >=20 > MFC after: 2 months There have been updates since then (for example): 321664 321719 321723 322320 322326 (lldb so might not count) 322360 (lldb so might not count) 322474 (lldb so might not count) 322740 322855 323112 323245 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Sep 7 06:58:45 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20D46E0BF7C; Thu, 7 Sep 2017 06:58:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB3D280E35; Thu, 7 Sep 2017 06:58:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::11b8:8ff2:8d47:fe2b] (unknown [IPv6:2001:470:7a58:0:11b8:8ff2:8d47:fe2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AAA3D374FB; Thu, 7 Sep 2017 08:58:41 +0200 (CEST) From: Dimitry Andric Message-Id: <2CE282A4-AF8C-47EC-944D-EB9686204DCA@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head/lib/clang/freebsd_cc_version.h , FREEBSD_CC_VERSION : When is it supposed to update? Date: Thu, 7 Sep 2017 08:58:36 +0200 In-Reply-To: <77543DF5-251C-438E-92A2-06574A687F9F@dsl-only.net> Cc: FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <77543DF5-251C-438E-92A2-06574A687F9F@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 06:58:45 -0000 --Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Sep 2017, at 01:54, Mark Millard wrote: >=20 > When is: >=20 > head/lib/clang/freebsd_cc_version.h >=20 > supposed to have: >=20 > FREEBSD_CC_VERSION >=20 > updated? Back on 2016-May-23 Bryan Drewery wrote on the lists: >=20 >> A critical note to toolchain developers, or anyone who touches the = Clang >> or GCC source files. If you modify these files or add a new target >> architecture into Clang, please bump the revision in the appropriate = file: >=20 >=20 > (It has moved since then.) Does this still apply? >=20 > The most recent FREEBSD_CC_VERSION update was the clang 4 -> clang 5 = transition: For clang, I update FREEBSD_CC_VERSION much more conservatively now, since bumping it requires everybody to do a full compiler bootstrap during buildworld. Basically only when: * A major update is imported, such as going from 4.0.0 to 5.0.0. Since that touches many files, it is better to ensure all parts of world are built with the new major version. * There is a bug in the system compiler, preventing some or all users from building (parts of) world. -Dimitry --Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWbDuHAAKCRCwXqMKLiCW ow31AKDrFP3FLPOi3NcsVm2zCjVuZ751aQCcDPNbUwJDQxRckDHobzZFUWLkXJY= =6iQX -----END PGP SIGNATURE----- --Apple-Mail=_A0283FE9-8C8B-4148-80A7-E91AEFE99FB0-- From owner-freebsd-toolchain@freebsd.org Thu Sep 7 18:24:08 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA8B6E06F92 for ; Thu, 7 Sep 2017 18:24:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-90.reflexion.net [208.70.210.90]) (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 246496E322 for ; Thu, 7 Sep 2017 18:24:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29259 invoked from network); 7 Sep 2017 18:26:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 Sep 2017 18:26:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 07 Sep 2017 14:24:05 -0400 (EDT) Received: (qmail 18338 invoked from network); 7 Sep 2017 18:24:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Sep 2017 18:24:05 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E74CCEC7848; Thu, 7 Sep 2017 11:24:04 -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: clang 5 vs. building the head's -r323246 kernel for TARGET_ARCH=powerpc : system ld aborts; other notes Message-Id: <0F28DDCB-1B8C-465E-99C9-EB1BBD7A520F@dsl-only.net> Date: Thu, 7 Sep 2017 11:24:04 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 18:24:08 -0000 The attempt to build head -r323246 via the system clang 5 stops for the likes of: --- agp.ko.full --- ld: agp.kld(.text+0x2e08): R_PPC_PLTREL24 reloc against local symbol agp.kld: could not read symbols: Bad value *** [agp.ko.full] Error code 1 There is a build-race and other instance of "R_PPC_PLTREL24 reloc = against local symbol" sometimes occurs instead. Also not much of the kernel = builds before this happens. The problem is not new with -r323246 . Back in clang 4 days I did not have this problem. I give the build details later below. There is a report of: --- ahd_pci.o --- /usr/src/sys/dev/aic7xxx/ahd_pci.c:113:10: warning: implicit conversion = from 'long long' to 'bus_addr_t' (aka 'unsigned int') changes value from = 549755813887 to 4294967295 [-Wconstant-conversion] ? 0x7FFFFFFFFF ~~^~~~~~~~~~~~ /usr/src/sys/dev/aic7xxx/aic_osm_lib.h:149:7: note: expanded from macro = 'aic_dma_tag_create' lowaddr, highaddr, filter, filterarg, = \ ^~~~~~~ before it stops. The code in question is: if (sizeof(bus_addr_t) > 4) ahd->flags |=3D AHD_39BIT_ADDRESSING; /* Allocate a dmatag for our SCB DMA maps */ error =3D aic_dma_tag_create(ahd, = /*parent*/bus_get_dma_tag(dev), /*alignment*/1, /*boundary*/0, (ahd->flags & AHD_39BIT_ADDRESSING) ? 0x7FFFFFFFFF : BUS_SPACE_MAXADDR_32BIT, /*highaddr*/BUS_SPACE_MAXADDR, /*filter*/NULL, /*filterarg*/NULL, /*maxsize*/BUS_SPACE_MAXSIZE_32BIT, /*nsegments*/AHD_NSEG, /*maxsegsz*/AHD_MAXTRANSFER_SIZE, /*flags*/0, &ahd->parent_dmat); So it is actually using BUS_SPACE_MAXADDR_32BIT but it still complains about the extra bits in the other case. So (bus_addr_t) 0x7FFFFFFFFF might be appropriate to avoid such warnings. For completeness: there are also reports of . . . --- if_ale.o --- /usr/src/sys/dev/ale/if_ale.c:2115:14: warning: taking address of packed = member 'rx_frames' of class or structure 'smb' may result in an = unaligned pointer value [-Waddress-of-packed-member] for (reg =3D &sb.rx_frames, i =3D 0; reg <=3D = &sb.rx_pkts_filtered; reg++) { ^~~~~~~~~~~~ /usr/src/sys/dev/ale/if_ale.c:2115:43: warning: taking address of packed = member 'rx_pkts_filtered' of class or structure 'smb' may result in an = unaligned pointer value [-Waddress-of-packed-member] for (reg =3D &sb.rx_frames, i =3D 0; reg <=3D = &sb.rx_pkts_filtered; reg++) { ^~~~~~~~~~~~~~~~~~~ /usr/src/sys/dev/ale/if_ale.c:2120:14: warning: taking address of packed = member 'tx_frames' of class or structure 'smb' may result in an = unaligned pointer value [-Waddress-of-packed-member] for (reg =3D &sb.tx_frames, i =3D 0; reg <=3D = &sb.tx_mcast_bytes; reg++) { ^~~~~~~~~~~~ /usr/src/sys/dev/ale/if_ale.c:2120:43: warning: taking address of packed = member 'tx_mcast_bytes' of class or structure 'smb' may result in an = unaligned pointer value [-Waddress-of-packed-member] for (reg =3D &sb.tx_frames, i =3D 0; reg <=3D = &sb.tx_mcast_bytes; reg++) { ^~~~~~~~~~~~~~~~~ . . . For the build-stopper there is: make[4]: stopped in /usr/src/sys/modules/agp .ERROR_TARGET=3D'agp.ko.full' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp.ko.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'ld -m elf32ppc_fbsd -Bshareable -znotext -d -warn-common = -o agp.ko.full agp.kld;' .CURDIR=3D'/usr/src/sys/modules/agp' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICv= tsc-NODBG/modules/usr/src/sys/modules/agp' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc' = MAKEOBJDIRPREFIX=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys= /GENERICvtsc-NODBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/= sbin:/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/usr/bin= :/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/legacy/bin:/usr/ob= j/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/sbin:/usr/obj/powerpcv= tsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bi= n' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvt= sc-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.powerpc-clang-bootstrap.amd64-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/agp/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/agp/../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/agp /usr/src/sys/dev/agp = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG' 1 error Build details: The build was a amd64 -> powerpc cross build: # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-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.powerpc-clang-bootstrap.amd64-h= ost" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ make $* # more ~/src.configs/make.conf CFLAGS.gcc+=3D -v # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG # # GENERIC -- Custom configuration for the powerpc/powerpc # include "GENERIC" ident GENERICvtsc-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Sep 9 02:44:09 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58C58E1E2B3 for ; Sat, 9 Sep 2017 02:44:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 166807647E for ; Sat, 9 Sep 2017 02:44:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27920 invoked from network); 9 Sep 2017 02:42:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 02:42:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 08 Sep 2017 22:37:27 -0400 (EDT) Received: (qmail 24610 invoked from network); 9 Sep 2017 02:37:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 02:37:27 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id D1BF6EC900E; Fri, 8 Sep 2017 19:37:26 -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: kernel-toolchain did not create stdint.h for amd64 -> arm64.aarch64 head -r323246 cross build so buildkernel failed Message-Id: <082FA59F-FC1E-40C9-964B-B11B7FDF1ECB@dsl-only.net> Date: Fri, 8 Sep 2017 19:37:25 -0700 To: FreeBSD Toolchain , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 02:44:09 -0000 The failure was: --- armv8_crypto_wrap.o --- In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/lib/clang/5.0.0/= include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found #include ^~~~~~~~~~ Context: # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323246M amd64 = amd64 1200043 1200043 # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 323246 Last Changed Rev: 323246 Note: The problem is repeatable. [Note: /usr/obj/cortexA53dbg_clang/arm64.aarch64/ was empty at the start of the below.] The failure was after: # = ~/sys_build_scripts.amd64-host/make_cortexA53_debug_clang_bootstrap-amd64-= host.sh -j14 kernel-toolchain Script started, output file is = /root/sys_typescripts/typescript_make_cortexA53_debug_clang_bootstrap-amd6= 4-host-2017-09-08:13:46:59 --- kernel-toolchain --- make[1]: "/usr/src/Makefile.inc1" line 688: META_MODE: Rebuilding host = tools due to ABI breakage in __FreeBSD_version 1200031. --- _worldtmp --- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/include mkdir -p /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/lib mkdir -p = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/lib/casper mkdir -p /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr mkdir -p = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/bin mkdir -p = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr . . . from which there was no stdint.h : # find /usr/obj/cortexA53dbg_clang/ -name stdint.h -print #=20 In more detail: # = ~/sys_build_scripts.amd64-host/make_cortexA53_debug_clang_bootstrap-amd64-= host.sh -j14 kernel-toolchain Script started, output file is = /root/sys_typescripts/typescript_make_cortexA53_debug_clang_bootstrap-amd6= 4-host-2017-09-08:13:46:59 --- kernel-toolchain --- make[1]: "/usr/src/Makefile.inc1" line 688: META_MODE: Rebuilding host = tools due to ABI breakage in __FreeBSD_version 1200031. --- _worldtmp --- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/include mkdir -p /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/lib mkdir -p = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/lib/casper mkdir -p /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr mkdir -p = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/bin mkdir -p = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr . . . Building = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/host-osreldate.h Script done, output file is = /root/sys_typescripts/typescript_make_cortexA53_debug_clang_bootstrap-amd6= 4-host-2017-09-08:13:46:59 # = ~/sys_build_scripts.amd64-host/make_cortexA53_debug_clang_bootstrap-amd64-= host.sh -j14 buildkernel Script started, output file is = /root/sys_typescripts/typescript_make_cortexA53_debug_clang_bootstrap-amd6= 4-host-2017-09-08:19:14:18 --- buildkernel --- --- buildkernel --- -------------------------------------------------------------- >>> Kernel build for GENERIC-DBG started on Fri Sep 8 19:14:18 PDT 2017 -------------------------------------------------------------- =3D=3D=3D> GENERIC-DBG mkdir -p /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- . . . --- armv8_crypto_wrap.o --- In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/lib/clang/5.0.0/= include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found #include ^~~~~~~~~~ --- all_subdir_armv8crypto --- 1 error generated. *** [armv8_crypto_wrap.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/armv8crypto .ERROR_TARGET=3D'armv8_crypto_wrap.o' = .ERROR_META_FILE=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/= GENERIC-DBG/modules/usr/src/sys/modules/armv8crypto/armv8_crypto_wrap.o.me= ta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'cc -mcpu=3Dcortex-a53 -target aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp = -B/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin -c -O3 = -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG/opt_glob= al.h -I. -I/usr/src/sys -fno-common -g -fPIC = -I/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG = -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall = -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef = -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value = -Wno-error-address-of-packed-member -std=3Diso9899:1999 -Werror = -march=3Darmv8-a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c; = ctfconvert -L VERSION -g armv8_crypto_wrap.o;' .CURDIR=3D'/usr/src/sys/modules/armv8crypto' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG/modules/usr/src/sys/modules/armv8crypto' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' = MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/= GENERIC-DBG/modules' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/s= bin:/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/bin:/= usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/bin:/usr/obj/c= ortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/sbin:/usr/obj/cortexA53dbg= _clang/arm64.aarch64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DB= G/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.cortexA53dbg-clang-bootstrap.amd64-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/armv8crypto/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/armv8crypto/../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/armv8crypto /usr/src/sys/crypto/armv8 = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG' 1 error =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Sep 9 03:34:57 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20214E21BB1 for ; Sat, 9 Sep 2017 03:34:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 D33377C628 for ; Sat, 9 Sep 2017 03:34:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15011 invoked from network); 9 Sep 2017 03:34:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 03:34:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 08 Sep 2017 23:34:55 -0400 (EDT) Received: (qmail 14498 invoked from network); 9 Sep 2017 03:34:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 03:34:54 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3789BEC7888; Fri, 8 Sep 2017 20:34:54 -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 -r 323246 /usr/src/sys/arm64/arm64/pmap.c:. . . error: no previous prototype for function 'pmap_invalidate_page' (also pmap_invalidate_range and pmap_invalidate_all) Message-Id: Date: Fri, 8 Sep 2017 20:34:53 -0700 Cc: FreeBSD Toolchain To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 03:34:57 -0000 This was from an amd64 -> arm64.aarch64 cross build context and was an attempt to build a debug kernel. # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323246M amd64 = amd64 1200043 1200043 # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 323246 Last Changed Rev: 323246 --- pmap.o --- /usr/src/sys/arm64/arm64/pmap.c:903:1: error: no previous prototype for = function 'pmap_invalidate_page' [-Werror,-Wmissing-prototypes] pmap_invalidate_page(pmap_t pmap, vm_offset_t va) ^ /usr/src/sys/arm64/arm64/pmap.c:917:1: error: no previous prototype for = function 'pmap_invalidate_range' [-Werror,-Wmissing-prototypes] pmap_invalidate_range(pmap_t pmap, vm_offset_t sva, vm_offset_t eva) ^ /usr/src/sys/arm64/arm64/pmap.c:934:1: error: no previous prototype for = function 'pmap_invalidate_all' [-Werror,-Wmissing-prototypes] pmap_invalidate_all(pmap_t pmap) ^ . . . 3 errors generated. *** [pmap.o] Error code 1 make[2]: stopped in = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG .ERROR_TARGET=3D'pmap.o' = .ERROR_META_FILE=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/= GENERIC-DBG/pmap.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -mcpu=3Dcortex-a53 -target aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp = -B/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin -c -O = -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt = -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h = -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only = -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall = -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef = -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value = -Wno-error-address-of-packed-member -std=3Diso9899:1999 -Werror = /usr/src/sys/arm64/arm64/pmap.c; ctfconvert -L VERSION -g pmap.o;' = .CURDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-D= BG' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/s= bin:/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/usr/bin:/= usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/legacy/bin:/usr/obj/c= ortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/sbin:/usr/obj/cortexA53dbg= _clang/arm64.aarch64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/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.cortexA53dbg-clang-bootstrap.amd64-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 Makefile = /usr/src/sys/conf/kern.pre.mk /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/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk = /usr/src/sys/conf/kern.mk' .PATH=3D'. = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG' 1 error # grep -r pmap_invalidate_page /usr/src/sys/arm64/ | more /usr/src/sys/arm64/arm64/pmap.c:pmap_invalidate_page(pmap_t pmap, = vm_offset_t va) /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(kernel_pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(kernel_pmap, kernel_vm_end); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, sva); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: pmap_invalidate_page(pmap, va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); /usr/src/sys/arm64/arm64/pmap.c: = pmap_invalidate_page(pmap, pv->pv_va); I will note that WERROR=3D was not in use: # more ~/src.configs/src.conf.cortexA53dbg-clang-bootstrap.amd64-host=20 TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} # KERNCONF=3DGENERIC-DBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D #MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # #CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. I will note that there are other architectures with the likes of: /usr/src/sys/i386/include/pmap.h:void pmap_invalidate_page(pmap_t, = vm_offset_t); /usr/src/sys/mips/mips/pmap.c:static void pmap_invalidate_page(pmap_t = pmap, vm_offset_t va); /usr/src/sys/amd64/include/pmap.h:void pmap_invalidate_page(pmap_t, = vm_offset_t); =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Sep 9 19:06:04 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12D88E02F13; Sat, 9 Sep 2017 19:06:04 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 E84B574110; Sat, 9 Sep 2017 19:06:03 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 467C08B24; Sat, 9 Sep 2017 19:06:03 +0000 (UTC) From: Jan Beich To: Warner Losh Cc: freebsd-arm@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: FCP-100: armv7 plan References: Date: Sat, 09 Sep 2017 21:05:57 +0200 In-Reply-To: (Warner Losh's message of "Fri, 8 Sep 2017 17:11:04 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:06:04 -0000 Warner Losh writes: > Greetings, > > This will serve as 'Last Call' for any objections to the plan to create an > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. [...] Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific differences between armv6 and armv7. Clang appears to enable NEON for all *-gnueabi* targets but I have no clue about GCC. Apparently, Android and Debian don't assume NEON on armv7. related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 From owner-freebsd-toolchain@freebsd.org Sat Sep 9 19:14:38 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91D3DE0372F for ; Sat, 9 Sep 2017 19:14:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 58C1B746FC for ; Sat, 9 Sep 2017 19:14:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id c195so9627283itb.1 for ; Sat, 09 Sep 2017 12:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e33g3XNtCEg4FWZf6sC7BLlQC1u2IX17wsYyu/4FFLA=; b=o2FCRr0qRqH3IKfbdBrGa42RYF7HPCkkQ/RrdIq9k6n2CHa6gzYRF9pTK9U2U7ukVP nv/SDY9QOIO7+QNhEYoeHAphs9Q4H6HHFmBdHMvapzcrXmQOe07mWvTTsAMlOvSQ+PV7 v/BTCW0FMxk3ylHi3GFRGBLNprpwG/A0pEbB5P6HhowJh6lO/pU/rq7UfKpVSGsYQFLh 58L053Ga+KW8W1XCSv6DrsNgYUvhylK/9fNfJzptl+7W0mfnPO/n0HM9FtGGD5MDRPEB k/+nRhUgZQAtKFZ/TSYQkTBItAuyTK1ZDlzr+FCCWlHineVpB8xvSw4tfnzGOgS7p2tn PgSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e33g3XNtCEg4FWZf6sC7BLlQC1u2IX17wsYyu/4FFLA=; b=YMMVNd720bcCVB7MyDoW+2z1ERYngaaJhJ0y9vBhxmPDERJ4jT0oSiy3f0OX3hPEtZ 7a3IR5oyiN1RK+ZRkvle4JquPIjugVPbM83311JKygS6o3Wbnh/jmb76AxTQXwivIqrI WUTLPruX25jyYsjyYc08WrkEa3Rt9u6M6eEU60Ta6Ge71qGANiGq6f+YV8tvM/SfOPkX 2hDxA6cOk4fKPxxCwW7kUQy8CUgVgkVmsVGj31CZqf1ZqYccPREnMM2REd+oo8I4LH+1 3vp9IiyrPSQmuIdrQ81OjzIfVw5+yzi7CBnw+gqUJchrb8g7zjfIqMYpXydDq0JUh1Ww xJyA== X-Gm-Message-State: AHPjjUhYnhVbfQWqr8ORcAzpRGh4WmYozdddd3vWaORpQw+xPoK0ictc 8338K5N5537GpT4zDAKi1/DAcVdM8GsB X-Google-Smtp-Source: ADKCNb6VUAvLjylT8s5N6cMdXB99HZNHrCRyBRrbYNu3CXqwfMvel1ob1k1eGgjhNFGDshJfmTbUAkVOwIlbH+sz0N8= X-Received: by 10.36.179.79 with SMTP id z15mr6751027iti.26.1504984477612; Sat, 09 Sep 2017 12:14:37 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sat, 9 Sep 2017 12:14:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: References: From: Warner Losh Date: Sat, 9 Sep 2017 13:14:36 -0600 X-Google-Sender-Auth: KJHYwfDDv7VqBMFbUwbmtcC92VA Message-ID: Subject: Re: FCP-100: armv7 plan To: Jan Beich Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:14:38 -0000 On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > Warner Losh writes: > > > Greetings, > > > > This will serve as 'Last Call' for any objections to the plan to create > an > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > [...] > > Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific > differences between armv6 and armv7. Clang appears to enable NEON for all > *-gnueabi* targets but I have no clue about GCC. Apparently, Android and > Debian don't assume NEON on armv7. > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > Yes. We are vague about it on purpose. Just like we're vague about MMX, MMX2, etc on x86 because different processors can/want use different things. The goal, if it doesn't work already, is for NEON to work if used, but not be required, just like all the other optional features of a CPU. Warner From owner-freebsd-toolchain@freebsd.org Sat Sep 9 19:25:06 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDF16E0412F; Sat, 9 Sep 2017 19:25:06 +0000 (UTC) (envelope-from jbeich@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 9DD3874E11; Sat, 9 Sep 2017 19:25:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id DCDDB90BE; Sat, 9 Sep 2017 19:25:05 +0000 (UTC) From: Jan Beich To: Warner Losh Cc: Jan Beich , "freebsd-arm\@freebsd.org" , "freebsd-toolchain\@FreeBSD.org" Subject: Re: FCP-100: armv7 plan References: Date: Sat, 09 Sep 2017 21:25:01 +0200 In-Reply-To: (Warner Losh's message of "Sat, 9 Sep 2017 13:14:36 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:25:06 -0000 Warner Losh writes: > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > >> Warner Losh writes: >> >> > Greetings, >> > >> > This will serve as 'Last Call' for any objections to the plan to create >> an >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. >> [...] >> >> Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific >> differences between armv6 and armv7. Clang appears to enable NEON for all >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android and >> Debian don't assume NEON on armv7. >> >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 >> > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > MMX2, etc on x86 because different processors can/want use different > things. Do you mean similar to how FreeBSD i386 is vague about not supporting real i386, only i486 or later? > The goal, if it doesn't work already, is for NEON to work if used, > but not be required, just like all the other optional features of a CPU. FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you mean at compile time? If so then the following probably needs to change $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C304E04D57 for ; Sat, 9 Sep 2017 19:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 0B47D75658 for ; Sat, 9 Sep 2017 19:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id d16so11342473ioj.3 for ; Sat, 09 Sep 2017 12:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hNgamjOla/fUYYmfjkSsuJufKvKKpBKx38Yz73F+9QM=; b=n8+vNeQNjo6eqqsDr03vDmUX3hTi1DCu64MRoalSJtskVP0OC1/u49ikZnKnABEh3m hnzQS6CG1jQvkVZq/MoLsW6QQfKYu9sUzjEkvn787/myC3Ogb/zp0Bxv9Dni6j2uT09r A3+GAI4ji+cdSKLS4GxCyofhuGiORWnoB4v8vhJUiOMNbvCjovd3RmJ41kWIA9wQpbiz eUIE78xKM7R5t+QeCAQv9GS9r37LbG1o2PlnaouB9FX47K9AWMW/KRcKDHL88VPsnjva jNfBEMzEzkPJk25ftQXcRQFws9rbBr4OkPKUsGTgzd8ME6KLFJ8iLxrMQcF1lD6bELDZ JaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hNgamjOla/fUYYmfjkSsuJufKvKKpBKx38Yz73F+9QM=; b=qIXhLFYKMM8zxIaG0TQiQ19mDvXrJULzQtnl2rhAtotl5cRTb/VWfQys/EjusTTK7/ TCFMUliu3RceYZTD2nTfAadNDFtNihl3z2dcF1f2k27v8fOUGJBGFwuMlmgLYWQTJAZv UWMJN0rfsv6Y7wFmAkYLW4xa05zNdungFVJmwUb06QHDOFKYNTR6muIHx6yOI6FCmAID C9dN31c6Bn8G6ehAUUoUkl6NdxFxvqhFawzHZvG29OGjvVEYAqRGrSt9f7n00uiBfLQ+ lYLy3MgF/79+IBwCn7obdnCX638tA3O2A1r+Rs0TTLlu1vOh0YrzttY3CfGdHeWN1Fen b0IQ== X-Gm-Message-State: AHPjjUjsxp5p7JdIXWd0VGCco6QtuYi4Sa+CorhNxZCDVzXtnIaHE+yd SpEiJMQZPw5MMn843JBVIYyNRf5/vfYz X-Google-Smtp-Source: ADKCNb4AJesL/DbFzhMF7oAJUl8UoISnGkWzT3UV/cNiZ+IGD4YgmZoRc0dOIrd7zqx3+Lpf4spgH0pm6dvSdBs3mvE= X-Received: by 10.107.133.92 with SMTP id h89mr2169841iod.208.1504985862229; Sat, 09 Sep 2017 12:37:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sat, 9 Sep 2017 12:37:41 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: References: From: Warner Losh Date: Sat, 9 Sep 2017 13:37:41 -0600 X-Google-Sender-Auth: S-uaDnKzj6IxnJFRcCFJxdspke0 Message-ID: Subject: Re: FCP-100: armv7 plan To: Jan Beich Cc: Jan Beich , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:37:43 -0000 On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh writes: > >> > >> > Greetings, > >> > > >> > This will serve as 'Last Call' for any objections to the plan to > create > >> an > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > >> [...] > >> > >> Some ports want NEON support but FCP-0100 is vague about > FreeBSD-specific > >> differences between armv6 and armv7. Clang appears to enable NEON for > all > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android and > >> Debian don't assume NEON on armv7. > >> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > >> > > > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > > MMX2, etc on x86 because different processors can/want use different > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? I mean we don't enumerate the list of all the processor supported things. We default to compiling for a fairly middle of the road processor, but you can strip that back all the way to i486, or hyper optimize for the latest core-2 duo. However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best to avoid by declaring the two different. One may be able to run armv6 binaries on an armv7 CPUs still, but we're not specifically guaranteeing it. > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. No, I don't mean that at all. I mean we don't care if it is enabled or not. It doesn't affect the ABI. The kernel knows about the extensions and saves the context when it's in use, just like the x86 kernel saves MMX, etc context when it's in use. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > Right. that's based on the default target. gcc/clang can enable or disable it (and a dozen other things) depending on what options you give. We don't care. We'll run all binaries. It's up to the system integrator to mix/match the options so they get optimal performance for their platform. Just like on x86. If you compile for MMX and run it on 486 w/o run-time detection, you'll get a reserved instruction fault. Same philosophy here. We don't dictate policy for the binaries, just like on x86. However, most of them have run-time detection to be nicer to the users than a core dump, and most do the best thing for that CPU if they really care about performance, but those applications that don't can just do whatever and be fine. Warner From owner-freebsd-toolchain@freebsd.org Sat Sep 9 20:05:04 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6837E06D02 for ; Sat, 9 Sep 2017 20:05:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 78D547714C for ; Sat, 9 Sep 2017 20:05:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 348 invoked from network); 9 Sep 2017 20:05:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 20:05:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 09 Sep 2017 16:05:02 -0400 (EDT) Received: (qmail 630 invoked from network); 9 Sep 2017 20:05:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 20:05:02 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id CBAE3EC86EF; Sat, 9 Sep 2017 13:05:01 -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: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places Message-Id: Date: Sat, 9 Sep 2017 13:05:01 -0700 To: FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:05:04 -0000 [The example here happens to be for amd64 -> aarch64 cross builds.] The following is from after copying/moving the kernel from where it was originally, such as (locally) installed on the build machine. Example of symbolic links from some recent activity under head -r323246 (producing -r323246 again): # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 = /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017 = /media/boot/kernel/if_igb.ko -> = /usr/obj/DESTDIRs/clang-cortexA53-installkernel/boot/kernel/if_em.ko In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes would not exist for booting the PINE64 that the USB SSD is for: so file not found if a usage attempt is made. Installing absolute path links messes up even the /boot/kernel.old/ handling unless that process carefully replaces the original link that was in /boot/kernel/ . In the /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko example I made a copy of the installed /mnt/boot/kernel/ area while the drive was still mounted. In the /usr/obj/DESTDIRs/ case I had installed to the local file system before attaching the USB SSD it was to be copied to. A relative path would not have such problems with binding to the wrong file or to no file when copies are made or renames along the path are done. [This has come up before on the lists, multiple-times as I remember.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Sep 9 20:10:54 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 300ADE072F4; Sat, 9 Sep 2017 20:10:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 F051877688; Sat, 9 Sep 2017 20:10:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id f84so3102678pfj.3; Sat, 09 Sep 2017 13:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=rrb3oyTOx+EhSQqV0092UgjHyYHAWg7/IOAGpJ35YJA=; b=kJuFb0/alBgBIH0x7a3n2iN6zUA94e1mNOUIpyUEp4DGZBE8OuLRMlauWFZQkbvQTl +2aHeuTFoc1Q+AcFzHeIsYN4RlR9WTlpJnmwHqym385efv+rN6NnjenDEMLVafOfT5yd 0Ulp7pK9gVTd6Xf9mBEBupvhHZHO5dvtJqxPlyCcXv4tQMI7mvcKRofGPnsz6bY86nUH cKWMaDQwzs1Twt8Cq12RTf5Tj2y2l0HDmNz9k5ep+V++K9i/MwdAWxmaPRJRGaAx54OH fuMi+7s7aYO98o4SJ3ztjHT56tzS4JXWscnb7NF3EWEkXm5geCXexGTxPM/nhy1nPqLK VZ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=rrb3oyTOx+EhSQqV0092UgjHyYHAWg7/IOAGpJ35YJA=; b=MYY3koLeAKSgfdMl8Gh84SWeiRyi/0QLhDBhMtJBafnuHG22URplpzbKRCcq24HBfa v2gJ9GsxRE47Njx1nyHqvDRVUEIsI2nRkO88rgz+JXs8cQ0UjaNwZvsTgyqWrTZtyB5d mdnDIAzasXc22qqtgA/41IragqSePkI6NqlqAlxKcygJmumHLBDoDGY/Ee8uYPMBLjtY jFDtXT/CpdsX9KLjE+OgkFMV/neVY9NB3o3dnNpITIU2HDtB2KIJssa1W8/34mcwhSGA l0jliauJFz91qYUYl2soEuy4o7fTYkJGrDkMH7wXwZx3OK+OzJgX/l7KV6QBI/UnHAuG BcPg== X-Gm-Message-State: AHPjjUi+FTdduOqQRnnlImGMHf2afqT/lETQw23kctiCcJGn0bkdxnmP Qa9LDw4OlWqI9gPgqoIeBA== X-Google-Smtp-Source: ADKCNb5HiTdrMqzmCwvKIX62fsVmjxwPg3+cgp82MJlO+Mcuq3VYr1K7ZB3qdAvWRExQZ+GoUUXzDg== X-Received: by 10.84.210.45 with SMTP id z42mr7951078plh.132.1504987853521; Sat, 09 Sep 2017 13:10:53 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id q12sm8096058pgs.47.2017.09.09.13.10.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Sep 2017 13:10:52 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170909201051.6545490.68027.31617@gmail.com> Date: Sat, 09 Sep 2017 13:10:51 -0700 Subject: Re: FCP-100: armv7 plan From: Russell Haley In-Reply-To: References: To: Warner Losh , Jan Beich Cc: freebsd-arm@freebsd.org, "freebsd-toolchain@FreeBSD.org" , Jan Beich X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:10:54 -0000 Warner,=A0 So you are saying NEON support is a compile time option that has no relevan= ce to the Application Binary Interface, which is what the FCP-0100 was abou= t? Thanks for clarification, Russ Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Virgin=A0Mobil= e=A0network. =A0 Original Message =A0 From: Warner Losh Sent: Saturday, September 9, 2017 12:37 PM To: Jan Beich Cc: freebsd-arm@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh writes: > >> > >> > Greetings, > >> > > >> > This will serve as 'Last Call' for any objections to the plan to > create > >> an > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > >> [...] > >> > >> Some ports want NEON support but FCP-0100 is vague about > FreeBSD-specific > >> differences between armv6 and armv7. Clang appears to enable NEON for > all > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android a= nd > >> Debian don't assume NEON on armv7. > >> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221898 > >> > > > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > > MMX2, etc on x86 because different processors can/want use different > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? I mean we don't enumerate the list of all the processor supported things. We default to compiling for a fairly middle of the road processor, but you can strip that back all the way to i486, or hyper optimize for the latest core-2 duo. However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best to avoid by declaring the two different. One may be able to run armv6 binaries on an armv7 CPUs still, but we're not specifically guaranteeing it. > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. No, I don't mean that at all. I mean we don't care if it is enabled or not. It doesn't affect the ABI. The kernel knows about the extensions and saves the context when it's in use, just like the x86 kernel saves MMX, etc context when it's in use. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > Right. that's based on the default target. gcc/clang can enable or disable it (and a dozen other things) depending on what options you give. We don't care. We'll run all binaries. It's up to the system integrator to mix/match the options so they get optimal performance for their platform. Just like on x86. If you compile for MMX and run it on 486 w/o run-time detection, you'll get a reserved instruction fault. Same philosophy here. We don't dictate policy for the binaries, just like on x86. However, most of them have run-time detection to be nicer to the users than a core dump, and most do the best thing for that CPU if they really care about performance, but those applications that don't can just do whatever and be fine. Warner _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sat Sep 9 20:34:13 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0690E0890E for ; Sat, 9 Sep 2017 20:34:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 91E8B7C998 for ; Sat, 9 Sep 2017 20:34:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 44f804e6-959e-11e7-950d-03a3531dacf2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 44f804e6-959e-11e7-950d-03a3531dacf2; Sat, 09 Sep 2017 20:34:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v89KYArr004518; Sat, 9 Sep 2017 14:34:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504989250.32063.66.camel@freebsd.org> Subject: Re: FCP-100: armv7 plan From: Ian Lepore To: Jan Beich , Warner Losh Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Date: Sat, 09 Sep 2017 14:34:10 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:34:13 -0000 On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > Warner Losh writes: > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > wrote: > > > > > > > > Warner Losh writes: > > > > > > > > > > > Greetings, > > > > > > > > This will serve as 'Last Call' for any objections to the plan > > > > to create > > > an > > > > > > > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > [...] > > > > > > Some ports want NEON support but FCP-0100 is vague about FreeBSD- > > > specific > > > differences between armv6 and armv7. Clang appears to enable NEON > > > for all > > > *-gnueabi* targets but I have no clue about GCC. Apparently, > > > Android and > > > Debian don't assume NEON on armv7. > > > > > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > > > > > Yes. We are vague about it on purpose. Just like we're vague about > > MMX, > > MMX2, etc on x86 because different processors can/want use > > different > > things. > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? > > > > > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a > > CPU. > FreeBSD doesn't support detecting NEON at runtime unlike Linux. We should fix that.  In fact, we should probably fix it in exactly the way linux does it (does it today, I think it's their 3rd scheme so far), using getauxval() and elf AT_HWCAP. Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure what to do about getauxval().  To be maximally linux-compatible (which would be good for ports) we'd put getauxval() in libc and make it work just like the linux one.  That's a bit at odds with the support we have now, which is procstat_getauxv() in libprocstat.  It's not very compatible with how linux getauxval() works, so using just that might lead to a lot of patches in ports. -- Ian > Do you > mean at compile time? If so then the following probably needs to > change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - |& fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > _______________________________________________ From owner-freebsd-toolchain@freebsd.org Sat Sep 9 21:30:32 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3C34E0B413 for ; Sat, 9 Sep 2017 21:30:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 758D87E34F for ; Sat, 9 Sep 2017 21:30:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id 6so7497058itl.1 for ; Sat, 09 Sep 2017 14:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bYn8uCIw8A2pSEpIETK8KvSe+49m3Zmlu+EGfxWv2FM=; b=IxFjiS6p5F3vZ4EbdqyDGEotPR11/aZWx7ZQbLR7Rur/UzqxzmpaeMUQ55BUoDbVwZ 35CzbP9JRvOnQT98r+8eiWAgApVPeHA6cHcxz24u1eqSDrXNsqkfJuijM0tqKPCr26wG gn6bg4RclEFpC527l5xXi/DzxBYQ+ymQlkMktJPJBsN3XpdwgxHOWQVktuOvTATmznnz XIdt8jMkYEwIFqyP8DVRjJir6MRfU4ToM9HEsEUHJ4l8qZCzGtPek+Gy+cONpSLU2rgC OU7swR2lHm1btXroEYIuZT5nTxhjscc9hEgfgcINuFdn0VwurJdEXHKMWB9XBWYpcDqb q6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bYn8uCIw8A2pSEpIETK8KvSe+49m3Zmlu+EGfxWv2FM=; b=lcwWwl6UWPI1t7uPhkUFnzdxaCImmgLWy4E3l+rPE4+mfagut2LBzkrJi9UaIuI2eB DOaAK3yr6NZmXxdmpvn+zgaRG00rswFGjcxNZiHeFPJxAs0e1DflqPJHgCqhM3iFad7n Nqg/x9aNII6megsVR1CSeqJgfEyWOo+SI6hBVqHOBSII+mmwOqRmulwLAA9iO4HV1TFT Ev0YceQIik8MesH1i2+BfOsjfmy0vvuqN/Zt8JrPd6c9G0p+SmZUIycsc8FMfjrUa0Zw gzWSxpi7o+GjnmQS8Ju7Y48oXJF9BfxtTlk+41cEtTcbb2ayBmZ8ETT38USVin8/ikPM 6m+A== X-Gm-Message-State: AHPjjUgxAyd86zTyaeui5iJXRlyfpMXBzj4W55e4X+G8502LXk9q5aKD A1xyUjXBCoDweC4x4zOW+rOpVrIewO6f X-Google-Smtp-Source: AOwi7QBjyc8n06qjygRXant/iIXDSqkDtnQgQH8/h08nN23D+0XY0l709Rcv374YEBeiKG5LizIQztwmt3okYiA7GFs= X-Received: by 10.36.34.75 with SMTP id o72mr6383586ito.15.1504992630854; Sat, 09 Sep 2017 14:30:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Sat, 9 Sep 2017 14:30:30 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: <1504989250.32063.66.camel@freebsd.org> References: <1504989250.32063.66.camel@freebsd.org> From: Warner Losh Date: Sat, 9 Sep 2017 15:30:30 -0600 X-Google-Sender-Auth: Mj0y30Ff8y1Ck3Y7q6B2OR-FhWI Message-ID: Subject: Re: FCP-100: armv7 plan To: Ian Lepore Cc: Jan Beich , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 21:30:32 -0000 On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore wrote: > On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote: > > Warner Losh writes: > > > > > > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich > > > wrote: > > > > > > > > > > > Warner Losh writes: > > > > > > > > > > > > > > Greetings, > > > > > > > > > > This will serve as 'Last Call' for any objections to the plan > > > > > to create > > > > an > > > > > > > > > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > > [...] > > > > > > > > Some ports want NEON support but FCP-0100 is vague about FreeBSD- > > > > specific > > > > differences between armv6 and armv7. Clang appears to enable NEON > > > > for all > > > > *-gnueabi* targets but I have no clue about GCC. Apparently, > > > > Android and > > > > Debian don't assume NEON on armv7. > > > > > > > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 > > > > > > > Yes. We are vague about it on purpose. Just like we're vague about > > > MMX, > > > MMX2, etc on x86 because different processors can/want use > > > different > > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > > real i386, only i486 or later? > > > > > > > > The goal, if it doesn't work already, is for NEON to work if used, > > > but not be required, just like all the other optional features of a > > > CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. > > We should fix that. In fact, we should probably fix it in exactly the > way linux does it (does it today, I think it's their 3rd scheme so > far), using getauxval() and elf AT_HWCAP. > Ah, yes. We should do that. We need that for other reasons as well. It shouldn't be too hard, though I don't know where we get the AT_HWCAP from to start with. > Adding the AT_HWCAP stuff would be relatively easy. I'm not as sure > what to do about getauxval(). To be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. That's a bit at odds with the support we have > now, which is procstat_getauxv() in libprocstat. It's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. Totally agreed, even if it means breaking compatibility with the past. And as important as these issues are, they are orthogonal to armv7 :) Warner -- Ian > > > Do you > > mean at compile time? If so then the following probably needs to > > change > > > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - > |& fgrep -i neon > > #define __ARM_NEON 1 > > #define __ARM_NEON_FP 0x4 > > #define __ARM_NEON__ 1 > > _______________________________________________ > > From owner-freebsd-toolchain@freebsd.org Sat Sep 9 21:46:12 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDAB3E0C457; Sat, 9 Sep 2017 21:46:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 60C027EC7D; Sat, 9 Sep 2017 21:46:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v89Lk6YT093622 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 00:46:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v89Lk6YT093622 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v89Lk6Dp093621; Sun, 10 Sep 2017 00:46:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Sep 2017 00:46:06 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Jan Beich , Warner Losh , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich Subject: Re: FCP-100: armv7 plan Message-ID: <20170909214606.GW1700@kib.kiev.ua> References: <1504989250.32063.66.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1504989250.32063.66.camel@freebsd.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 21:46:12 -0000 On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy. šI'm not as sure > what to do about getauxval(). šTo be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. šThat's a bit at odds with the support we have > now, which isšprocstat_getauxv() in libprocstat. šIt's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). From owner-freebsd-toolchain@freebsd.org Sat Sep 9 22:08:07 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F7EFE0D89B; Sat, 9 Sep 2017 22:08:07 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 2B41A7FA3F; Sat, 9 Sep 2017 22:08:07 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pg0-x241.google.com with SMTP id d8so2898845pgt.3; Sat, 09 Sep 2017 15:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=EKV8fCc5VyDKWhoWJb6JDGSZORvNKr3idKWPzt7bF4Y=; b=K1OfHGbvLOu5GOz64Dp8UUKMtC+76FP3iVXumZMW9HGFIX21FEnyXiyIRfXa6DRN3I tS5JA1KwC++69W51nl80BaBJxjV0uAHbbIg7fgFmMrq4u+nRTpXVW13TVxvAJnX4tjXM 0LzmyUzSTG731L2D0L2gmsMtQXaz/yr46uacFeyy0MLf+nEZfTBBi0NdJoYgTsD1ZEGk m/fmrASfRk0CZWrokvYb/zuTjwiaA2GYfg1K9GKnfIzOslcuV904dGQaeXe/v+MjUrgp 2tin/1hYOzZv6vuEzhIbqnmuCyPad6t/su2MQcfI6p4j7ObenXlo68E5E7NZlV54bpzI IXSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=EKV8fCc5VyDKWhoWJb6JDGSZORvNKr3idKWPzt7bF4Y=; b=kF3eNbz/x3q/9dqdO9Aw2N5fnZbnBIc9MzruYAumpVBVFrvo318lRUlX+kfQ0Kj3uD QxUlWfAa8iktVmXQinIooGXcTmuEJE3JmyWup+uAvEe9ju3UbEQIB361g+pMlmvHZouo HBHWsXz11MCVZmK0PZ0leViZqESj+77J4UypKc1YpeXyeUKDJeIc0nNodvg6pqbABLYm m8d8Z5E8F3fLtUqvJwB8NBn/AmyTSFvdlv75mOTM76RSiQJWqXissE1MZl35Twen1/JT oQERZ8p7NYLwaf0YPlZApHc/EFpy41Lc29/ozASZ88COAi/94f1RroK96aFUD7Ovj4Aq gMPw== X-Gm-Message-State: AHPjjUgq7j07kIA25DtEfWvfnlo9iGeCibhgX5EpqSnRcKWzgx0rEzE1 ZRPzhU8aZljybA== X-Google-Smtp-Source: ADKCNb7CxJ+/kxHi8uZcIODordHDZpVdwQ9Zg0zaazdHl39iq3Rv77DmyliuVwb+fFdSzoRvZRTBUg== X-Received: by 10.99.37.66 with SMTP id l63mr7390467pgl.348.1504994886468; Sat, 09 Sep 2017 15:08:06 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id r11sm9944328pfg.180.2017.09.09.15.08.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Sep 2017 15:08:04 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170909220804.6545490.97876.31623@gmail.com> Date: Sat, 09 Sep 2017 15:08:04 -0700 Subject: Getauxval - was Re: FCP-100: armv7 plan From: Russell Haley In-Reply-To: <20170909214606.GW1700@kib.kiev.ua> References: <1504989250.32063.66.camel@freebsd.org> <20170909214606.GW1700@kib.kiev.ua> To: Konstantin Belousov , Ian Lepore Cc: freebsd-arm@freebsd.org, "freebsd-toolchain@FreeBSD.org" , Jan Beich , Jan Beich X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:08:07 -0000 Apologies for the top post.=C2=A0 Man pages indicate =E2=80=8Egetauxval is a non standard glibc function. Is = this an issue? Is there a more posix way I could compare against? I was pre= viously wondering to myself if the Linux api is now more standard than the = posix api? Looking forward to all opinions and comments.=C2=A0 Rus Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Virgin=C2=A0Mobile=C2=A0network. =C2=A0 Original Message =C2=A0 From: Konstantin Belousov Sent: Saturday, September 9, 2017 2:46 PM To: Ian Lepore Cc: freebsd-arm@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich; Jan = Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy. =C2=A0I'm not as sure > what to do about getauxval(). =C2=A0To be maximally linux-compatible (whi= ch > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. =C2=A0That's a bit at odds with the support we h= ave > now, which is=C2=A0procstat_getauxv() in libprocstat. =C2=A0It's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sat Sep 9 22:32:36 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5622AE0EAC3; Sat, 9 Sep 2017 22:32:36 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0123.outbound.protection.outlook.com [104.47.34.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDCC2804DB; Sat, 9 Sep 2017 22:32:35 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ixvOBB79moCbUvaqIc3uOM+TmYsZRWflbeBi+Nx9Xfc=; b=ICXFR0YxKFomRhNWvcxyydSik2qzh0AhEzbL/htLjEvU8DS43YynHQJreojbTrNODMiJAYEfxgDy1dFVhaW189s4WyOPXr5WAneOGz/6Rvej80MQBDPtY9YWYNeKhZuKCMtYB0or7ZRJU8NHKTKM3tFRZbNyHbY4KuOMEbIrZbs= Received: from BN3PR05CA0029.namprd05.prod.outlook.com (10.174.64.39) by BN3PR0501MB1217.namprd05.prod.outlook.com (10.160.113.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Sat, 9 Sep 2017 22:32:34 +0000 Received: from DM3NAM05FT043.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by BN3PR05CA0029.outlook.office365.com (2603:10b6:400::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4 via Frontend Transport; Sat, 9 Sep 2017 22:32:34 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; dsl-only.net; dkim=none (message not signed) header.d=none;dsl-only.net; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT043.mail.protection.outlook.com (10.152.98.112) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.1.1385.11 via Frontend Transport; Sat, 9 Sep 2017 22:32:33 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 9 Sep 2017 15:31:51 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v89MVoIx014156; Sat, 9 Sep 2017 15:31:51 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D8823385520; Sat, 9 Sep 2017 15:31:50 -0700 (PDT) To: Mark Millard CC: FreeBSD Toolchain , FreeBSD Current , Subject: Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places In-Reply-To: References: Comments: In-reply-to: Mark Millard message dated "Sat, 09 Sep 2017 13:05:01 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75574.1504996310.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Sep 2017 15:31:50 -0700 Message-ID: <75575.1504996310@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(199003)(24454002)(189002)(97736004)(6266002)(6246003)(189998001)(5660300001)(7126002)(23726003)(2950100002)(55016002)(97756001)(6916009)(305945005)(356003)(117636001)(229853002)(478600001)(4326008)(69596002)(46406003)(110136004)(9686003)(54906002)(86362001)(7696004)(107886003)(105596002)(53416004)(76506005)(77096006)(106466001)(2906002)(2810700001)(47776003)(50986999)(76176999)(50226002)(68736007)(97876018)(53936002)(81166006)(81156014)(8676002)(8936002)(8746002)(50466002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1217; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT043; 1:Y+gf4p4OcgoaQkz4rcmeA0hSSuBpfJ/5xuB2m6gCmaHeXNqVRvbfRT90vPceQ43l5oS4tCePg8OPl0xGmO60GcQWtSoERQPkimrntobZ74R0xSwC7TkUBaA8S9pO1r48 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8958f594-efdc-4dc7-ed26-08d4f7d2aa1b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1217; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 3:OkK6C9BQyphwVTgBAED5xT/ACTTKzfAInf+Ztbxw69uIGW2NesvQgPaf2PXnHTQ0uPY3thYuelv04wIDRwCa2BW1ATBdayhvUGzSDRnOV9BxmdfAMRflMtMJaIXq8QYmzPQF0YilXnnNoiy2FnFBGCbgIIJT20QArlNn5HWtuhqjfDIpDFH2XJEcE36nsvLrcxh4kg1sI02aygKo5ehDQFHkzjZvxNWWRRmeNQrocOXctyQCYJFtVN55MdpmHRCNLvCdG19T/dzZlr9C4vWwFPMK2H2erwJ0x7sIFFws0AGifHpEf/Wu8ddcZYOdLdBmLpOCnFnr6IPOZMZQwnt9YliLy7Sd3hgZnpxvHjH8xFc=; 25:dKB9gAyvh16bfPCu7tTvFNMYkSlniml6hy0dV2VCUleUZH6rZugGHG5F0ST9zFA9aTW9lg4WAMytB9vprghy/yvemd5g9p0fMK+Aovd8Mw3m1QTZEuNq0FRcZ0GD+gdWxljf2+2Cd4TzXwy7Eb44mkJG1z+kYO0tn4xU1D/4jUSZdq6pvXQY/z5EGz5pDtEVpb70OI1DeHVp3MPknDsEBJLRESjVObWVg92LKNgkj48jHpbUKy9U4R9rAakNNeBqhs3I0+EUpkRWA5A4e0vuHztBFEH1KTQoWyk/RrthtG3NThBf/uR/ddPdwlPIZEt+cx3BQwoLXxVQXzb/+1J4hQ== X-MS-TrafficTypeDiagnostic: BN3PR0501MB1217: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 31:eCWvEMEEOj1nqTZus2d29kKIRzT2yL/L3DWVxay2NZk24LTJBKaBm1tpmMrphyf1YnhDkhmhawyjqQwGuimNFpLfJobK/jsu0D3XQ06hp8SzOWcEAoLvGMlyvbGy8o5NSyR3fskeTRgBcSQaS41U59UzyHOsFlTcACBni1zSp3boYQkM0smOFZmtTNGXwoa5Qho7gZuole8AN05SVkX7cNo7hmwRJgxcsBfwBpLwXL8=; 20:H7TCPpsX4CId2qhC412q4fRrJFiwiD/24EMAz5OHxjaprfU//TRkr8p32R6a9Y61qIyDGPf1Su7KRzrAgva38PwuA5JuRqt4BpjFkbTu+KkHgh1Pfs6pw1KZAI1H087JBJSnDrub5SmdZ+5lFJEf2/4b09x9pnAr1wAEj1Tt1zUtZDLIxZBVukfwZCdysqDmfUpzCQd431d1Bg/7nw1aFg6F1EzCUNYJqMnHIdt9uRXrvSRvixZrjkd+sS46zt3hv6gWLjW9kmR9x7q2/CPHQu9bCfJvcMEE+zjYicH67VA5/vjypFzsgpupPkSZCCffIyb1FWni74P/7aABwPLX0Bu7MIi1LTIEPrXfBuoXgiPWwPZ4hrzv0X05IE1A8E3lRiJ3IqVsv5iGRxxjtgROjr5OLEdbAIPLn3OcT7XWJOACvgVUYiqd6R8YzdTJVt8L6mv9CyxnJa3HF00JnW91u+Wc2k/YV9bJmcudQGEUKM85ZSvFn0eCkhKiOhrexcQA X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93003095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1217; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1217; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 4:bwpscJEPSmnVVMXK/1HFeupHrYCB1pOLS5f9wHSIkCnKqdgGiJAIOflKmUucfFf6cSIqPVG6EGCttAwdjHNMbS8EGnoZKAW7IvI0uWdfoqIQf1WiT2HeFvHq85LAdtI+Dv32KI/rzclUExV6nIi54co6a7yQGDqQ1MR76LEfyVqDuHU0kxsYC1aSpNuzWW58FIKpWNAF9QZU0hx6S7suZrJk/ADAFtAGwDJl2zu4JyeK2QsjK22LCI6bgz3Dv7vr X-Forefront-PRVS: 0425A67DEF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1217; 23:yNlFN/O0W91Vvlpe4a5P0JG/Cx1BoS2J3Knn+1y?= =?us-ascii?Q?0D/VhFUjtV7yubxTsLEe0doxVLhnhb9LEA65FiO/NWZCdXVldABK53EkibKf?= =?us-ascii?Q?a2D5qJjE6CJlaFVFPd/Eo6ZA3Ufgz6s0OJePRzglFoCG+XbfjdaWidYCw0CH?= =?us-ascii?Q?55JhDaBy8Efg4ajDi2pBArw3nEZIm6ArZulq1NuYV15fdY9uaWBq0/4NHqHS?= =?us-ascii?Q?ozrOtNRPvPaBRqihY31+W3cBGOr8YuiY630/WDk7P5ubk0qXRig/XedMYQRp?= =?us-ascii?Q?wKXeMZXpysDBZmtDyfGA1mvda4wDEUd/2pi2XcRs6ODYDUqoGQNJfDDqXv10?= =?us-ascii?Q?416ZgY+XZRXz/+bzwJI+wS/ZyP1Ibt04KjGhlSduBz+8usR+LBh+bksSBWdZ?= =?us-ascii?Q?jL43IigWRlg9EHSEJFAaol4iHcMbK5j+1+Xu0WqyG5Qrinq4Uubat7FVuY/w?= =?us-ascii?Q?keo6OlLFGZkl0GtbwmaPKMN73j0hW4I5mUqOa35sGo7koVzSBizDKiUKNjoV?= =?us-ascii?Q?+pFcUK17VGgZ7eOnvBgflW4qoe5j1vEMvqkiomZM8+9Ku2ExbW7QvbjAb6oY?= =?us-ascii?Q?095ehGmAmSs4omdo+4fTzjEtSETmbUd2tdyHF9BtLEmrQdXJi/xdxfMgK6Vz?= =?us-ascii?Q?uEcpNBh6H1yGpqAFEE7HWRxP0lgICyhR3/E5ITrQQYbLjFiMsqRTliaVbw+T?= =?us-ascii?Q?bA7T1YsLDL2z+h3BlhX9hGBjdhrPqmZtpjdiNfFPMknMtCavtolc6J7MAWGi?= =?us-ascii?Q?KU8jEOttJ5894mE3amatKRugh+DWL/15Ob8r+hFyIUEFGS4ZVJhgYfuHPAqK?= =?us-ascii?Q?XdiSf7ndmG7nbRD1GY5HAONc4U4aZ6r1vF+wJiF9Ntt70BNeJe6xTyvO04Nc?= =?us-ascii?Q?5vW5tvCfpfgxrnCyYVpU0s2fdNaH/6NPD4afRSqb1wnG6cKIO5YUiQ+KfYjV?= =?us-ascii?Q?hH1G8Dkzn7+HU5pHhCj9gkVoZ0KC37Wq6XxB8C+8j0VpbUr4O5YKtn7dQCH4?= =?us-ascii?Q?iHXJsJlimsPm1+JpGsGBJijILEfE9qRT6ArRKjq6fFAtIIwZDIMoYCXrzdqG?= =?us-ascii?Q?FFIx5C+70gFzSSmw6aijRCCfUaKWOYfh9P7cPBv9bwwogCyIHkGHtyqEG0lV?= =?us-ascii?Q?XgxxwAlhb+u9WQ0Gs6Nqt3E3iG05mzgbFr7ePi/1A43VeXrdcqmsQhtQmv1R?= =?us-ascii?Q?RhNuUX9KIfFOYnvh5M7na7IUixs4urGp8nR06SuDKVQMxtw3wZ5jfehqJaw?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1217; 6:F0j90OhP8l1zmvHiemFqpEh9ZfwF6xZBRKu930Prg+/m9k1YwzWlelcP+69XHIaRfT0xw3Drf9aMQKZHiBk+glOTcnLWvuP923cvvw8wzczE+J6Ath658ZxAMwHJoGdZPg3PigtMSAHHdOyJhHTwu2z6/CY1Ho9QBMIb84lJgEBg5KPid9E8gTG2XE9vHfXqFvQOymlpzpH5V0zdC/rBukDodvL5+XVY2AM//X1GibFg1ou0HTvgCjQGamWVfIH+Q/385lJA7UITaYHZyKFpCe9mahwJOiqM3ipRsxAx83qWUasBdGtBjM2mpqB1S9gkbbbY/Qij6i3YTqOE5ojlDA==; 5:KFmNu3wRsliRiKMxW8rBP7HmcdCbFwZZJuXnZ2g+csOufCly+lTB7tDVS5KmAdX2YmCVYMHk/N7pdJCwyQRuHZSGd+trBwsL0iOFnyXXiSuVz7FC6eJUgIhsZ1jim2qcDOuwhihlgy4An+HyTMUX6g==; 24:N+Qz6kG4tT3b+e5+6y6mfqNUXShThl+sZKuh3NPkmaxJAGhYB5I7aTZLNs63LKLwm6/cKuEQK33Hhwqgbfhfui/sQD8fzvXv68tTCheoLUU=; 7:YMC35mytO0VkfG/AjZ6DyZ3F8/0VhnMtdT/97z+3oTR/rjKldB0HSeoRvVB/qewx6LeF1M7vQSPHsN4NUF+wj5O280HlIWw4VK90CPyOyP21R3nKw7++ebyTFsil3qheZ6p8KlelK/Okw6fv+CnQsE93UMYgImD/kQe3a2ISON5u/E2DY5GSO1ck6TIZqb8fl173r2legr99Iu2Wg8Ud+m8612e6XQPz0qvYRbLu714= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2017 22:32:33.1950 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1217 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:32:36 -0000 Mark Millard wrote: > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko > lrwxr-xr-x 1 root wheel 25 Sep 8 22:47:36 2017 /mnt/boot/kerndb/if_i= gb.ko -> /mnt/boot/kernel/if_em.ko > lrwxr-xr-x 1 root wheel 68 Sep 6 20:27:20 2017 /media/boot/kernel/if= _igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53-installkernel/boot/kernel/if_= em.ko > = > In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes > would not exist for booting the PINE64 that the USB SSD is for: > so file not found if a usage attempt is made. Yes, when making symlinks in presence of DESTDIR, the src should have $DESTDIR removed - the following should usually be safe: ln -s ${src#$DESTDIR} $DESTDIR${target#$DESTDIR} From owner-freebsd-toolchain@freebsd.org Sat Sep 9 22:36:59 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2281E0EEE0; Sat, 9 Sep 2017 22:36:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACF4780708; Sat, 9 Sep 2017 22:36:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [50.235.236.73]) by mail.baldwin.cx (Postfix) with ESMTPSA id BEA7610A7B9; Sat, 9 Sep 2017 18:36:51 -0400 (EDT) Subject: Re: FCP-100: armv7 plan To: Jan Beich , Warner Losh References: Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" , Jan Beich From: John Baldwin Message-ID: Date: Sat, 9 Sep 2017 18:36:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sat, 09 Sep 2017 18:36:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:36:59 -0000 On 9/9/17 3:25 PM, Jan Beich wrote: > Warner Losh writes: > >> On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: >> >>> Warner Losh writes: >> The goal, if it doesn't work already, is for NEON to work if used, >> but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 Re: runtime, I have patches in review to add AT_HWCAP for native FreeBSD/arm binaries. Right now it doesn't support a NEON hwcap but it should be easy to add the flag using the same check to enable it that Linux does. -- John Baldwin From owner-freebsd-toolchain@freebsd.org Sat Sep 9 22:53:53 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66C9EE0FD2F for ; Sat, 9 Sep 2017 22:53:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 4879680EA1 for ; Sat, 9 Sep 2017 22:53:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: bb51ea2f-95b1-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id bb51ea2f-95b1-11e7-b50b-53dc5ecda239; Sat, 09 Sep 2017 22:53:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v89MriRK004711; Sat, 9 Sep 2017 16:53:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504997624.32063.69.camel@freebsd.org> Subject: Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places From: Ian Lepore To: "Simon J. Gerraty" , Mark Millard Cc: FreeBSD Toolchain , FreeBSD Current Date: Sat, 09 Sep 2017 16:53:44 -0600 In-Reply-To: <75575.1504996310@kaos.jnpr.net> References: <75575.1504996310@kaos.jnpr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 22:53:53 -0000 On Sat, 2017-09-09 at 15:31 -0700, Simon J. Gerraty wrote: > Mark Millard wrote: > > > > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko > > lrwxr-xr-x  1 root  wheel  25 Sep  8 22:47:36 2017 > > /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko > > lrwxr-xr-x  1 root  wheel  68 Sep  6 20:27:20 2017 > > /media/boot/kernel/if_igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53- > > installkernel/boot/kernel/if_em.ko > > > > In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes > > would not exist for booting the PINE64 that the USB SSD is for: > > so file not found if a usage attempt is made. > Yes, when making symlinks in presence of DESTDIR, the src should have > $DESTDIR removed - the following should usually be safe: > > ln -s ${src#$DESTDIR} $DESTDIR${target#$DESTDIR} > I think the modern fix for this would be "install -l rs $src $DESTDIR", that should result in if_igb.ko -> if_em.ko without any dir nodes in the link. -- Ian From owner-freebsd-toolchain@freebsd.org Sat Sep 9 23:35:15 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 839ECE11B61 for ; Sat, 9 Sep 2017 23:35:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 35BBE81FE8 for ; Sat, 9 Sep 2017 23:35:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25113 invoked from network); 9 Sep 2017 23:35:13 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Sep 2017 23:35:13 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Sat, 09 Sep 2017 19:35:13 -0400 (EDT) Received: (qmail 23670 invoked from network); 9 Sep 2017 23:35:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2017 23:35:12 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3AA97EC94E5; Sat, 9 Sep 2017 16:35:12 -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: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64 Message-Id: Date: Sat, 9 Sep 2017 16:35:11 -0700 To: FreeBSD Toolchain , freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 23:35:15 -0000 The context here is head -r323246 amd64 -> arm64/aarch64 cross build activity. =46rom installkernel : # find /usr/obj/DESTDIRs/clang-cortexA53-installkernel/ -name "*.dtb" = -print #=20 =46rom buildkernel : # find /usr/obj/cortexA53_clang/arm64.aarch64/ -name "*.dtb" -print #=20 =46rom installing u-boot-pine64 : # ls -lTd /usr/local/share/u-boot/u-boot-pine64/* -rw-r--r-- 1 root wheel 125 Sep 6 00:49:44 2017 = /usr/local/share/u-boot/u-boot-pine64/README -rw-r--r-- 1 root wheel 505940 Sep 6 00:49:43 2017 = /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin As stands the file must be manually produced. crochet goes to the trouble to have logic to build and install pine64_plus.dtb (based on arm64/pine64_plus.dts ). Is pine64_plus.dtb required for the likes of Pine64+ 2GB's? If yes: should it be automatically built and installed someplace for arm64/aarch64 builds (even if more manual steps are required to have the final placement on the Pine64 media)? =3D=3D=3D Mark Millard markmi at dsl-only.net