From owner-freebsd-toolchain@freebsd.org Sun Dec 4 01:15:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33E2EC57209 for ; Sun, 4 Dec 2016 01:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08F262EA for ; Sun, 4 Dec 2016 01:15:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB41Fl5u015615 for ; Sun, 4 Dec 2016 01:15:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Sun, 04 Dec 2016 01:15:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 01:15:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 --- Comment #5 from Mark Millard --- (In reply to Mark Millard from comment #3) I showed the wrong SRC_ENV_CONF file. It should have been (using the system compiler): # more ~/src.configs/src.conf.powerpc64-clang_altbinutils.powerpc64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D # world32/usr/src/lib/csu/powerpc/crti.o got: # csu/powerpc/crti.S:34:13: error: unexpected token in memory operand # csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 'mflr' # and the like. So avoid LIB32. WITHOUT_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang -B ${CROSS_BINUTILS_PREFIX} CXX=3D/usr/bin/clang++ -B ${CROSS_BINUTILS_PREFIX} CPP=3D/usr/bin/clang-cpp -B ${CROSS_BINUTILS_PREFIX} .export CC .export CXX .export CPP AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Dec 4 02:54:11 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32431C66266 for ; Sun, 4 Dec 2016 02:54:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA63B1C90 for ; Sun, 4 Dec 2016 02:54:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9703 invoked from network); 4 Dec 2016 02:54:10 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Dec 2016 02:54:10 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 03 Dec 2016 21:54:14 -0500 (EST) Received: (qmail 14088 invoked from network); 4 Dec 2016 02:54:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Dec 2016 02:54:14 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id DD783EC8AF4; Sat, 3 Dec 2016 18:54:02 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: head -r309179 powerpc64 WITH_LIB32= buildworld only works on powerpc64, not on cross build from amd64 Message-Id: Date: Sat, 3 Dec 2016 18:54:02 -0800 Cc: Justin Hibbits , Kevin Bowling , Roman Divacky To: Dimitry Andric , FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 02:54:11 -0000 I just discovered that, even though I could not build WITH_LIB32=3D for TARGET_ARCH=3Dpowerpc64 from amd64, after booting the cross built system I was able to buildworld using WITH_LIB32=3D based on the SRC_ENV_CONF that I list later. Installing, booting, and testing it works: # ldd32 /usr/lib32/libgcc_s.so.1=20 /usr/lib32/libgcc_s.so.1: libc.so.7 =3D> /usr/lib32/libc.so.7 (0x41841000) # file `which ldd32` /usr/bin/ldd32: ELF 32-bit MSB executable, PowerPC or cisco 4500, = version 1 (FreeBSD), dynamically linked, interpreter = /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200017), FreeBSD-style, = stripped The blocking issue on amd64's cross build was rejection of assembler notation used in lib32's build. Turns out from the message text details that the compiler was in either the ATT or the Intel instruction set parsing code when it rejected the notation. I have submitted a bugzilla report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215037 Supporting details for the on powerpc64 build: -r416639 devel/binutils -r407342 devel/powerpc-binutils (slave port so tracks devel/binutils in various ways) (The above avoids 2.47 vintages.) # head = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils_= world-powerpc64-host-2016-12-03:17:42:59=20 Script started on Sat Dec 3 17:42:59 2016 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-clang_altbinutils.powe= rpc64-host WITH_META_MODE=3Dyes = MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.= powerpc64 make -j 5 buildworld . . . # more = /root/src.configs/src.conf.powerpc64-clang_altbinutils.powerpc64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang -B ${CROSS_BINUTILS_PREFIX} CXX=3D/usr/bin/clang++ -B ${CROSS_BINUTILS_PREFIX} CPP=3D/usr/bin/clang-cpp -B ${CROSS_BINUTILS_PREFIX} .export CC .export CXX .export CPP AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Dec 4 04:36:00 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F54AC666C1 for ; Sun, 4 Dec 2016 04:36:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B857D171B for ; Sun, 4 Dec 2016 04:35:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21991 invoked from network); 4 Dec 2016 04:36:39 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Dec 2016 04:36:39 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 03 Dec 2016 23:35:59 -0500 (EST) Received: (qmail 13855 invoked from network); 4 Dec 2016 04:35:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Dec 2016 04:35:59 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3703BEC9143; Sat, 3 Dec 2016 20:35:51 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-Id: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> Date: Sat, 3 Dec 2016 20:35:50 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 04:36:00 -0000 [Note: At present I can buildworld using WITH_LIB32=3D on powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a minor variant of head -r309179 . That does not work for amd64 cross compiling to powerpc64 due to assembler notation rejections.] When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's clang 3.9.0 I get the following sorts of error reports, *even building on powerpc64* : --- hwpmc_e500.o --- /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 3,400 ^ . . . When I look up these instructions I find that they are not classic powerpc instructions: ( = http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd= f ) > Whereas the classic architecture defines special-purpose registers = (SPRs) and > two instructions to access them (Move to Special-Purpose Register = (mtspr) and > Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines > optional device control registers (DCRs) and mtdcr and mfdcr = instructions, and > the EIS-defined performance monitor APU defines performance monitor = registers > (PMRs) and mtpmr and mfpmr instructions, all based on models provided = by the > UISA. . . . Does this imply that clang 3.9.0 needs to support more instructions when it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64 and then override some items for my build activity.) If yes, then someone probably needs to make a list of what instructions need to be present and have someone submit the list into llvm's bugzilla and have the submittal listed in: [META] Using Clang as the FreeBSD/ppc system compiler (25780). If GENERIC64 does not need the likes of hwpmc_e500.o built then some work on the build environment to avoid GENERIC64 including things with non-classic instruction use would appear to be needed. (No llvm involvement for this case.) I doubt this is the case as it would seem that the problem would reoccur when alternate KERNCONF's were in use instead that do require something like of hwpmc_e500.o to be built. Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is = about this issue from the FreeBSD side of things. I just noticed the status of the specific instructions involved and also that the cross-build and on-powerpc64 build get the same result (unlike the recent WITH_LIB32=3D discovery). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Dec 4 05:14:43 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C646DC662AE for ; Sun, 4 Dec 2016 05:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B55B682E for ; Sun, 4 Dec 2016 05:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB45EhnU019131 for ; Sun, 4 Dec 2016 05:14:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation Date: Sun, 04 Dec 2016 05:14:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 05:14:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) I've now also tried this on a powerpc64 running a minor variant of head -r309179 and it gets the same result that the amd64 cross build for TARGET_ARCH=3Dpowerpc64 does --unlike the buildworld WITH_LIB32=3D issue now listed in bugzilla 215037. Here it seems that the "BOOK E" specific instructions are missing from the assembler notation that clang 3.9.0 supports for TARGET_ARCH=3Dpowerpc64. There might be other non-classic PowerPc instructions also missing for all I know. I've sent a note asking Justin Hibbits what he thinks the proper classification of this is. Does llvm need to support the BOOK E specific instructions on the assembler notation in order for FreeBSD to use clang as the system compiler? Even if GENERIC64 could avoid including such things there would still be the issue of how to allow more specialized builds to target BOOK E (or other variants with special instructions for the variant). This may need a related llvm bugzilla submittal to be listed in the: [META] Using Clang as the FreeBSD/ppc system compiler (25780 for llvm). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Dec 4 07:31:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA812C66EF1 for ; Sun, 4 Dec 2016 07:31:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D3F81EB for ; Sun, 4 Dec 2016 07:31:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25660 invoked from network); 4 Dec 2016 07:31:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 4 Dec 2016 07:31:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 04 Dec 2016 02:31:39 -0500 (EST) Received: (qmail 12799 invoked from network); 4 Dec 2016 07:31:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Dec 2016 07:31:39 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id DE4D0EC8AF4; Sat, 3 Dec 2016 23:31:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND [ WITH_LLVM_LIBUNWIND= based buildworld fails on powerpc64 for TARGET_ARCH=powerpc64 ] From: Mark Millard In-Reply-To: Date: Sat, 3 Dec 2016 23:31:38 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Dimitry Andric Content-Transfer-Encoding: 7bit Message-Id: <09B0D6F7-F2F3-4AA3-9EE6-5D51655549BE@dsl-only.net> References: <750FCE4D-F25B-46E1-9383-B8A94AAA8792@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 07:31:42 -0000 On 2016-Nov-29, at 2:56 PM, Ed Maste wrote: > On 29 November 2016 at 16:46, Mark Millard wrote: >> >> >> Summary: Does using clang 3.9.0 as the system compiler imply one should or >> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work? >> >> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria >> for what dwarfdump should show for the exception information (if the >> information to be shown is to be correct/sufficient for libunwind)? > > It does not. It should be possible to build a functional system both > WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the > _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind > data. > > Eventually new features may show up in Clang and LLVM's libunwind (and > new versions of GNU's unwinder) that won't work with the old unwinder. > >> Your answer's detail might indicate that I've misdirected the llvm folks >> in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 . >> >> There is also the question of if/when llvm's libunwind is ready to be used >> for powerpc64 or powerpc (or . . .) if there are architecture specifics >> involved. That answer might determine when C++ exceptions work (and so >> when devel/kyua might have a chance to work) and is sort of separate from >> the main question here but is still of interest overall. >> >> Should powerpc64 and powerpc clang 3.9.0 testing be using >> WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? > > For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My > eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, > and ELF Tool Chain on all of our supported architectures. I tried adding WITH_LLVM_LIBUNWIND= to the SRC_CONF_ENV file that I use on powerpc64 for TARGET_ARCH=powerpc64 for (a minor variation of) head -r309179 based on clang 3.9.0. It failed to complete buildworld: A) An assert failed in libunwind/src/UnwindCursor.hpp . B) Two .S files got massive numbers of error messages ( libgcc_eh/UnwindRegisterRestore.S and libgcc_eh/UnwindRegisterSave.S ) And those points stopped the build. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039 Note: using WITHOUT_LLVM_LIBUNWIND= (implicit) I've done buildworld using WITH_LIB32= just fine and rebooted with it installed and then did more buildworld experiments. The above started from a working environment for such things. Unfortunately for gcc's libunwind clang's code generation is broken (counting .eh dwarf information as code). C++ exceptions are one area that does not even do simple things correctly for powerpc64 (or for powerpc): I have to avoid using programs that depend on C++ exceptions happening. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Dec 5 16:27:13 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97DB9C68503; Mon, 5 Dec 2016 16:27:13 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 29F4C106F; Mon, 5 Dec 2016 16:27:12 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 503AEA35642; Mon, 5 Dec 2016 17:19:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1480954745; bh=E1KmZY+c9aRqJBBWpfR4XjDFEXTf8EqaCsyi39U/SaQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Z0jQCaVVoJaEGDuHW2+x2YD1RgM2+tCVk8DHLaJn1kVDbw7HZWsJew5isxxLC2I9/ u3bf1f0UWF1X7ScJEf9JvOdZ20bM2og3dem1Ujf/qed1n2X7Sa75w3+1g1lC9yH16P n5vUUo9gALDtMV3Ke0lvc+AC5dl0RE93Lj0qImkw= Date: Mon, 5 Dec 2016 17:19:05 +0100 From: Roman Divacky To: Mark Millard Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20161205161904.GA7889@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:27:13 -0000 Can you try this patch? Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td =================================================================== --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -2373,6 +2373,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle counter // on a 32-bit target. let hasSideEffects = 1, usesCustomInserter = 1 in On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > [Note: At present I can buildworld using WITH_LIB32= on > powerpc64 for TARGET_ARCH=powerpc64 via clang 3.9.0 from a > minor variant of head -r309179 . That does not work for > amd64 cross compiling to powerpc64 due to assembler > notation rejections.] > > When I attempt to buildkernel (with WERROR= ) via FreeBSD's > clang 3.9.0 I get the following sorts of error > reports, *even building on powerpc64* : > > --- hwpmc_e500.o --- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: unrecognized instruction mnemonic > uint32_t pmgc0 = mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg)); \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > . . . > > When I look up these instructions I find that they are not > classic powerpc instructions: > ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pdf ) > > > Whereas the classic architecture defines special-purpose registers (SPRs) and > > two instructions to access them (Move to Special-Purpose Register (mtspr) and > > Move from Special-Purpose Register (mfspr)), Book E takes that model and defines > > optional device control registers (DCRs) and mtdcr and mfdcr instructions, and > > the EIS-defined performance monitor APU defines performance monitor registers > > (PMRs) and mtpmr and mfpmr instructions, all based on models provided by the > > UISA. > > . . . > > Does this imply that clang 3.9.0 needs to support more instructions when > it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64 > and then override some items for my build activity.) > > If yes, then someone probably needs to make a list of what instructions > need to be present and have someone submit the list into llvm's bugzilla > and have the submittal listed in: > > [META] Using Clang as the FreeBSD/ppc system compiler > > (25780). > > > If GENERIC64 does not need the likes of hwpmc_e500.o built then some > work on the build environment to avoid GENERIC64 including things with > non-classic instruction use would appear to be needed. (No llvm > involvement for this case.) I doubt this is the case as it would > seem that the problem would reoccur when alternate KERNCONF's were > in use instead that do require something like of hwpmc_e500.o to be > built. > > > Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214903 is about > this issue from the FreeBSD side of things. I just noticed the status > of the specific instructions involved and also that the cross-build > and on-powerpc64 build get the same result (unlike the recent > WITH_LIB32= discovery). > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Tue Dec 6 00:32:01 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29F17C5933F for ; Tue, 6 Dec 2016 00:32:01 +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 E31EC18BF for ; Tue, 6 Dec 2016 00:32:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7030 invoked from network); 6 Dec 2016 00:06:08 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2016 00:06:08 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Mon, 05 Dec 2016 19:05:30 -0500 (EST) Received: (qmail 2149 invoked from network); 6 Dec 2016 00:05:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2016 00:05:30 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 947ABEC91F9; Mon, 5 Dec 2016 16:05:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <20161205161904.GA7889@vlakno.cz> Date: Mon, 5 Dec 2016 16:05:17 -0800 Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 00:32:01 -0000 On 2016-Dec-5, at 8:19 AM, Roman Divacky wrote: > Can you try this patch? >=20 > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2373,6 +2373,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; >=20 > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > + > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > // on a 32-bit target. > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in Direct use of the patch (put into a file) was rejected: # patch -p0 < llvmPPCInstrInfo_td.patch=20 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) -------------------------- Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, = (outs gprc:$RT), (ins i32imm:$SPR), So I hand put in the extra lines. I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 the MFTB line is at line number 2300 while your patch listed: @@ -2373,6 +2373,12 @@ My edit shows as: # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision = 309179) +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -2300,6 +2300,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; =20 +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle = counter // on a 32-bit target. let hasSideEffects =3D 1, usesCustomInserter =3D 1 in Unfortunately the buildkernel still gets the same errors: (This was tried after a kernel-toolchain .) # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met= a CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp= c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g = -fno-omit-frame-pointer = -I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr= c/sys/GENERIC64vtsc-NODBG -mno-altivec -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 -msoft-float = -std=3Diso9899:1999 -c = /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o CMD ctfconvert -L VERSION -g hwpmc_e500.o CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc TARGET hwpmc_e500.o -- command output -- /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 3,400 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, pmgc0); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic pmc_pmlc =3D mfpmr(PMR_PMLCa0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 10,144 ^ . . . =3D=3D=3D Mark Millard markmi at dsl-only.net Older content: On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > [Note: At present I can buildworld using WITH_LIB32=3D on > powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a > minor variant of head -r309179 . That does not work for > amd64 cross compiling to powerpc64 due to assembler > notation rejections.] >=20 > When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's > clang 3.9.0 I get the following sorts of error > reports, *even building on powerpc64* : >=20 > --- hwpmc_e500.o --- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > . . . >=20 > When I look up these instructions I find that they are not > classic powerpc instructions: > ( = http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd= f ) >=20 >> Whereas the classic architecture defines special-purpose registers = (SPRs) and >> two instructions to access them (Move to Special-Purpose Register = (mtspr) and >> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines >> optional device control registers (DCRs) and mtdcr and mfdcr = instructions, and >> the EIS-defined performance monitor APU defines performance monitor = registers >> (PMRs) and mtpmr and mfpmr instructions, all based on models provided = by the >> UISA. >=20 > . . . >=20 > Does this imply that clang 3.9.0 needs to support more instructions = when > it is targeting FreeBSD for GENERIC64 based builds? (I include = GENERIC64 > and then override some items for my build activity.) >=20 > If yes, then someone probably needs to make a list of what = instructions > need to be present and have someone submit the list into llvm's = bugzilla > and have the submittal listed in: >=20 > [META] Using Clang as the FreeBSD/ppc system compiler >=20 > (25780). >=20 >=20 > If GENERIC64 does not need the likes of hwpmc_e500.o built then some > work on the build environment to avoid GENERIC64 including things with > non-classic instruction use would appear to be needed. (No llvm > involvement for this case.) I doubt this is the case as it would > seem that the problem would reoccur when alternate KERNCONF's were > in use instead that do require something like of hwpmc_e500.o to be > built. >=20 >=20 > Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is = about > this issue from the FreeBSD side of things. I just noticed the status > of the specific instructions involved and also that the cross-build > and on-powerpc64 build get the same result (unlike the recent > WITH_LIB32=3D discovery). >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Dec 6 01:22:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B206EC66528 for ; Tue, 6 Dec 2016 01:22:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (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 770931747 for ; Tue, 6 Dec 2016 01:22:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7166 invoked from network); 6 Dec 2016 01:16:16 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2016 01:16:16 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Mon, 05 Dec 2016 20:16:20 -0500 (EST) Received: (qmail 6195 invoked from network); 6 Dec 2016 01:16:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2016 01:16:20 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 39960EC7977; Mon, 5 Dec 2016 17:16:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> Date: Mon, 5 Dec 2016 17:16:07 -0800 Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 01:22:50 -0000 [Top post of a retry using a different SRC_CONF_ENV file.] Well it looks like: WITHOUT_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D ignores the .td file change but WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D may use it. I had accidentally used a SRC_CONF_ENV file that was of the first form. So I've got a build going based on the 2nd form. . . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-5, at 4:05 PM, Mark Millard wrote: On 2016-Dec-5, at 8:19 AM, Roman Divacky wrote: > Can you try this patch? >=20 > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2373,6 +2373,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; >=20 > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > + > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > // on a 32-bit target. > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in Direct use of the patch (put into a file) was rejected: # patch -p0 < llvmPPCInstrInfo_td.patch=20 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) -------------------------- Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, = (outs gprc:$RT), (ins i32imm:$SPR), So I hand put in the extra lines. I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 the MFTB line is at line number 2300 while your patch listed: @@ -2373,6 +2373,12 @@ My edit shows as: # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision = 309179) +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -2300,6 +2300,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle = counter // on a 32-bit target. let hasSideEffects =3D 1, usesCustomInserter =3D 1 in Unfortunately the buildkernel still gets the same errors: (This was tried after a kernel-toolchain .) # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met= a CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp= c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g = -fno-omit-frame-pointer = -I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr= c/sys/GENERIC64vtsc-NODBG -mno-altivec -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 -msoft-float = -std=3Diso9899:1999 -c = /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o CMD ctfconvert -L VERSION -g hwpmc_e500.o CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc TARGET hwpmc_e500.o -- command output -- /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 3,400 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, pmgc0); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic pmc_pmlc =3D mfpmr(PMR_PMLCa0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 10,144 ^ . . . =3D=3D=3D Mark Millard markmi at dsl-only.net Older content: On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > [Note: At present I can buildworld using WITH_LIB32=3D on > powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a > minor variant of head -r309179 . That does not work for > amd64 cross compiling to powerpc64 due to assembler > notation rejections.] >=20 > When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's > clang 3.9.0 I get the following sorts of error > reports, *even building on powerpc64* : >=20 > --- hwpmc_e500.o --- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > . . . >=20 > When I look up these instructions I find that they are not > classic powerpc instructions: > ( = http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd= f ) >=20 >> Whereas the classic architecture defines special-purpose registers = (SPRs) and >> two instructions to access them (Move to Special-Purpose Register = (mtspr) and >> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines >> optional device control registers (DCRs) and mtdcr and mfdcr = instructions, and >> the EIS-defined performance monitor APU defines performance monitor = registers >> (PMRs) and mtpmr and mfpmr instructions, all based on models provided = by the >> UISA. >=20 > . . . >=20 > Does this imply that clang 3.9.0 needs to support more instructions = when > it is targeting FreeBSD for GENERIC64 based builds? (I include = GENERIC64 > and then override some items for my build activity.) >=20 > If yes, then someone probably needs to make a list of what = instructions > need to be present and have someone submit the list into llvm's = bugzilla > and have the submittal listed in: >=20 > [META] Using Clang as the FreeBSD/ppc system compiler >=20 > (25780). >=20 >=20 > If GENERIC64 does not need the likes of hwpmc_e500.o built then some > work on the build environment to avoid GENERIC64 including things with > non-classic instruction use would appear to be needed. (No llvm > involvement for this case.) I doubt this is the case as it would > seem that the problem would reoccur when alternate KERNCONF's were > in use instead that do require something like of hwpmc_e500.o to be > built. >=20 >=20 > Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is = about > this issue from the FreeBSD side of things. I just noticed the status > of the specific instructions involved and also that the cross-build > and on-powerpc64 build get the same result (unlike the recent > WITH_LIB32=3D discovery). >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Dec 6 01:42:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12753C66F58 for ; Tue, 6 Dec 2016 01:42:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (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 CB89031A for ; Tue, 6 Dec 2016 01:42:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20278 invoked from network); 6 Dec 2016 01:42:39 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Dec 2016 01:42:39 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Mon, 05 Dec 2016 20:42:46 -0500 (EST) Received: (qmail 22349 invoked from network); 6 Dec 2016 01:42:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2016 01:42:37 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 24F39EC7977; Mon, 5 Dec 2016 17:42:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: Date: Mon, 5 Dec 2016 17:42:28 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 01:42:41 -0000 On 2016-Dec-5, at 5:16 PM, Mark Millard wrote: > Well it looks like: >=20 > WITHOUT_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D >=20 > ignores the .td file change but >=20 > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D >=20 > may use it. >=20 > I had accidentally used a SRC_CONF_ENV file that > was of the first form. >=20 > So I've got a build going based on the 2nd form. . . No such luck: same type of failure at the same point. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-5, at 4:05 PM, Mark Millard wrote: On 2016-Dec-5, at 8:19 AM, Roman Divacky wrote: > Can you try this patch? >=20 > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2373,6 +2373,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; >=20 > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > + > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > // on a 32-bit target. > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in Direct use of the patch (put into a file) was rejected: # patch -p0 < llvmPPCInstrInfo_td.patch=20 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) -------------------------- Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, = (outs gprc:$RT), (ins i32imm:$SPR), So I hand put in the extra lines. I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 the MFTB line is at line number 2300 while your patch listed: @@ -2373,6 +2373,12 @@ My edit shows as: # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision = 309179) +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -2300,6 +2300,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle = counter // on a 32-bit target. let hasSideEffects =3D 1, usesCustomInserter =3D 1 in Unfortunately the buildkernel still gets the same errors: (This was tried after a kernel-toolchain .) # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met= a CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp= c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g = -fno-omit-frame-pointer = -I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr= c/sys/GENERIC64vtsc-NODBG -mno-altivec -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-e rror-unused-function -Wno-error-pointer-sign = -Wno-error-shift-negative-value -msoft-float -std=3Diso9899:1999 -c = /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o CMD ctfconvert -L VERSION -g hwpmc_e500.o CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc TARGET hwpmc_e500.o -- command output -- /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 3,400 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, pmgc0); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: = unrecognized instruction mnemonic mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); ^ ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) ^ :1:2: note: instantiated into assembly here mtpmr 400,3 ^ /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic pmc_pmlc =3D mfpmr(PMR_PMLCa0); ^ ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ ^ :1:2: note: instantiated into assembly here mfpmr 10,144 ^ . . . =3D=3D=3D Mark Millard markmi at dsl-only.net Older content: On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > [Note: At present I can buildworld using WITH_LIB32=3D on > powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a > minor variant of head -r309179 . That does not work for > amd64 cross compiling to powerpc64 due to assembler > notation rejections.] >=20 > When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's > clang 3.9.0 I get the following sorts of error > reports, *even building on powerpc64* : >=20 > --- hwpmc_e500.o --- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > . . . >=20 > When I look up these instructions I find that they are not > classic powerpc instructions: > ( = http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd= f ) >=20 >> Whereas the classic architecture defines special-purpose registers = (SPRs) and >> two instructions to access them (Move to Special-Purpose Register = (mtspr) and >> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines >> optional device control registers (DCRs) and mtdcr and mfdcr = instructions, and >> the EIS-defined performance monitor APU defines performance monitor = registers >> (PMRs) and mtpmr and mfpmr instructions, all based on models provided = by the >> UISA. >=20 > . . . >=20 > Does this imply that clang 3.9.0 needs to support more instructions = when > it is targeting FreeBSD for GENERIC64 based builds? (I include = GENERIC64 > and then override some items for my build activity.) >=20 > If yes, then someone probably needs to make a list of what = instructions > need to be present and have someone submit the list into llvm's = bugzilla > and have the submittal listed in: >=20 > [META] Using Clang as the FreeBSD/ppc system compiler >=20 > (25780). >=20 >=20 > If GENERIC64 does not need the likes of hwpmc_e500.o built then some > work on the build environment to avoid GENERIC64 including things with > non-classic instruction use would appear to be needed. (No llvm > involvement for this case.) I doubt this is the case as it would > seem that the problem would reoccur when alternate KERNCONF's were > in use instead that do require something like of hwpmc_e500.o to be > built. >=20 >=20 > Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is = about > this issue from the FreeBSD side of things. I just noticed the status > of the specific instructions involved and also that the cross-build > and on-powerpc64 build get the same result (unlike the recent > WITH_LIB32=3D discovery). >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Tue Dec 6 20:44:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA8CCC6B336 for ; Tue, 6 Dec 2016 20:44:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C98031AFA for ; Tue, 6 Dec 2016 20:44:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB6Kijm9019644 for ; Tue, 6 Dec 2016 20:44:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Tue, 06 Dec 2016 20:44:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:44:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Tue Dec 6 20:44:40 UTC 2016 New revision: 309656 URL: https://svnweb.freebsd.org/changeset/base/309656 Log: During the bootstrap phase, when building the minimal llvm library on PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream llvm revision r271821 disabled the use of std::call_once, which causes some fallback functions from Atomic.cpp to be used instead. Reported by: Mark Millard PR: 214902 X-MFC-With: 309124 Changes: head/lib/clang/libllvmminimal/Makefile --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Dec 6 20:47:00 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15D40C6B3E6 for ; Tue, 6 Dec 2016 20:47:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0350D1E12 for ; Tue, 6 Dec 2016 20:47:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB6Kkx0Q022864 for ; Tue, 6 Dec 2016 20:46:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214902] head -r309179 buildworld on powerpc64 via clang 3.9.0: llvm::sys::CompareAndSwap and llvm::sys::MemoryFence undefined so build stops Date: Tue, 06 Dec 2016 20:47:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc bug_status bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:47:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214902 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | CC| |dim@FreeBSD.org Status|New |In Progress Severity|Affects Only Me |Affects Some People --- Comment #7 from Dimitry Andric --- Mark, can you please verify that r309656 fixes this particular build issue, when building on PowerPC? I don't have access to any PowerPC hardware. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Dec 7 19:03:33 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC4A7C6C6A8; Wed, 7 Dec 2016 19:03:33 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3E26919B0; Wed, 7 Dec 2016 19:03:32 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 12999A35642; Wed, 7 Dec 2016 20:00:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1481137257; bh=LSHzhVjJ37HcNPKj3GP6Igcwd4+Wg7AuqVrye5L8fMk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gGwcOSriYdgBQ0uHRe6wglrmT3GTHGrRAarp/YjlTG9PsFsdsRjtCqw/fX4nOnMAO PXfcRIDde15c4w5O3Xc9v+oJkJgwMxadqt7LC6xT1IM6zeWwA4+oZSo8ay9Vop8ZOV xY6af6KuxjwMBmq5Do2nf/tOjOu/KHgNtCQhf6vI= Date: Wed, 7 Dec 2016 20:00:57 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20161207190057.GA58950@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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, 07 Dec 2016 19:03:33 -0000 Can the compiler you built with the patch process this file: typedef int register_t; #define mtpmr(reg, val) \ __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) #define mfpmr(reg) \ ( { register_t val; \ __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ val; } ) #define PMR_PMC0 16 int foo() { return mfpmr(PMR_PMC0); } I can compile it just fine locally. Not sure why it wouldnt work in your ca= se. On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote: > On 2016-Dec-5, at 5:16 PM, Mark Millard wrote: >=20 > > Well it looks like: > >=20 > > WITHOUT_CROSS_COMPILER=3D > > WITH_SYSTEM_COMPILER=3D > >=20 > > ignores the .td file change but > >=20 > > WITH_CROSS_COMPILER=3D > > WITHOUT_SYSTEM_COMPILER=3D > >=20 > > may use it. > >=20 > > I had accidentally used a SRC_CONF_ENV file that > > was of the first form. > >=20 > > So I've got a build going based on the 2nd form. . . >=20 > No such luck: same type of failure at the same point. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Dec-5, at 4:05 PM, Mark Millard wrote: >=20 > On 2016-Dec-5, at 8:19 AM, Roman Divacky wrote: >=20 > > Can you try this patch? > >=20 > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > @@ -2373,6 +2373,12 @@ > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > "mftb $RT, $SPR", IIC_SprMFTB>; > >=20 > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > > + > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > > + > > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > > // on a 32-bit target. > > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in >=20 > Direct use of the patch (put into a file) was rejected: >=20 > # patch -p0 < llvmPPCInstrInfo_td.patch=20 > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > -------------------------- > Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... > patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, (out= s gprc:$RT), (ins i32imm:$SPR), >=20 > So I hand put in the extra lines. >=20 > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 > the MFTB line is at line number 2300 while your patch listed: >=20 > @@ -2373,6 +2373,12 @@ >=20 > My edit shows as: >=20 > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 309179) > +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2300,6 +2300,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; >=20 > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > + > // A pseudo-instruction used to implement the read of the 64-bit cycle co= unter > // on a 32-bit target. > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in >=20 >=20 > Unfortunately the buildkernel still gets the same errors: > (This was tried after a kernel-toolchain .) >=20 > # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc= /hwpmc_e500.o.meta > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target powerpc64= -unknown-freebsd12.0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_k= ernel/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O= 2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KER= NEL_OPTION_HEADERS -include /usr/obj/powerpc64vtsc_clang_altbinutils_kernel= /powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/= src/sys -fno-common -g -fno-omit-frame-pointer -I/usr/obj/powerpc64vtsc_cla= ng_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG -m= no-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredun= dant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoin= ter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__f= reebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-erro= r-parentheses-equality -Wno-e > rror-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-va= lue -msoft-float -std=3Diso9899:1999 -c /usr/src/sys/modules/hwpmc/../../= dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o > CMD ctfconvert -L VERSION -g hwpmc_e500.o > CWD /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr= /src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc > TARGET hwpmc_e500.o > -- command output -- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: un= recognized instruction mnemonic > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: unr= ecognized instruction mnemonic > mtpmr(PMR_PMGC0, pmgc0); > ^ > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > ^ > :1:2: note: instantiated into assembly here > mtpmr 400,3 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: unr= ecognized instruction mnemonic > mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); > ^ > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > ^ > :1:2: note: instantiated into assembly here > mtpmr 400,3 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: un= recognized instruction mnemonic > pmc_pmlc =3D mfpmr(PMR_PMLCa0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 10,144 > ^ > . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > Older content: >=20 > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > > [Note: At present I can buildworld using WITH_LIB32=3D on > > powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a > > minor variant of head -r309179 . That does not work for > > amd64 cross compiling to powerpc64 due to assembler > > notation rejections.] > >=20 > > When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's > > clang 3.9.0 I get the following sorts of error > > reports, *even building on powerpc64* : > >=20 > > --- hwpmc_e500.o --- > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > > ^ > > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > > ^ > > :1:2: note: instantiated into assembly here > > mfpmr 3,400 > > ^ > > . . . > >=20 > > When I look up these instructions I find that they are not > > classic powerpc instructions: > > ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRM= RM.pdf ) > >=20 > >> Whereas the classic architecture defines special-purpose registers (SP= Rs) and > >> two instructions to access them (Move to Special-Purpose Register (mts= pr) and > >> Move from Special-Purpose Register (mfspr)), Book E takes that model a= nd defines > >> optional device control registers (DCRs) and mtdcr and mfdcr instructi= ons, and > >> the EIS-defined performance monitor APU defines performance monitor re= gisters > >> (PMRs) and mtpmr and mfpmr instructions, all based on models provided = by the > >> UISA. > >=20 > > . . . > >=20 > > Does this imply that clang 3.9.0 needs to support more instructions when > > it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64 > > and then override some items for my build activity.) > >=20 > > If yes, then someone probably needs to make a list of what instructions > > need to be present and have someone submit the list into llvm's bugzilla > > and have the submittal listed in: > >=20 > > [META] Using Clang as the FreeBSD/ppc system compiler > >=20 > > (25780). > >=20 > >=20 > > If GENERIC64 does not need the likes of hwpmc_e500.o built then some > > work on the build environment to avoid GENERIC64 including things with > > non-classic instruction use would appear to be needed. (No llvm > > involvement for this case.) I doubt this is the case as it would > > seem that the problem would reoccur when alternate KERNCONF's were > > in use instead that do require something like of hwpmc_e500.o to be > > built. > >=20 > >=20 > > Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is abo= ut > > this issue from the FreeBSD side of things. I just noticed the status > > of the specific instructions involved and also that the cross-build > > and on-powerpc64 build get the same result (unlike the recent > > WITH_LIB32=3D discovery). > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Thu Dec 8 00:11:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 101A4C6C988 for ; Thu, 8 Dec 2016 00:11:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (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 C88277E0 for ; Thu, 8 Dec 2016 00:11:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13600 invoked from network); 8 Dec 2016 00:11:50 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Dec 2016 00:11:50 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Wed, 07 Dec 2016 19:11:50 -0500 (EST) Received: (qmail 8231 invoked from network); 8 Dec 2016 00:11:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 00:11:50 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AF2CCEC7B39; Wed, 7 Dec 2016 16:11:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <20161207190057.GA58950@vlakno.cz> Date: Wed, 7 Dec 2016 16:11:48 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 00:11:58 -0000 On 2016-Dec-7, at 11:00 AM, Roman Divacky wrote: > Can the compiler you built with the patch process this file: >=20 > typedef int register_t; > #define mtpmr(reg, val) = \ > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > #define mfpmr(reg) = \ > ( { register_t val; = \ > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > val; } ) >=20 > #define PMR_PMC0 16 >=20 > int foo() > { > return mfpmr(PMR_PMC0); > } >=20 >=20 > I can compile it just fine locally. Not sure why it wouldnt work in = your case. I separately had helped with testing for bugzilla 214902 and so had updated to head -r309656 so the context was different. But I figured out the .td file related issue on powerpc64. My means of forcing all the compiles that target powerpc64 to use -B to pick up the alternate toolchain (since the bootstrap binutils ld can fail) also forced the system compiler to be used instead of the bootstrapped clang. (The SRC_CONF_ENV file that I used had the text that forced this.) So my buildkernel was using an unpatched compiler when I tried kernel-toolchain then buildkernel. This was visible in the .meta file part of my report on the problem. It showed: > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ instead of having the path to the bootstrap compiler. It turns out that my amd64 cross build SRC_CONF_ENV file also had remnants of an experiment that also happened to force the system compiler to be used so it would have got the same behavior. Based on use of compilers that actually have your patch in them. . . Your patch worked fine to let the buildkernel reach the next problem: use of -mminimial-toc in a kernel module is made but is rejected for powerpc64. Sorry for the extra noise in reporting on your patch. Trying to find new things to report (future problems) by working around existing problems that are known but unfixed tends to have these sorts of interferences. Of course sometimes my workarounds might not be the best ones available. This stupid mistake is probably what is going on in at least one bugzilla report that I submitted: So I've likely got more to clean up. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material. . . On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote: > On 2016-Dec-5, at 5:16 PM, Mark Millard = wrote: >=20 >> Well it looks like: >>=20 >> WITHOUT_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >>=20 >> ignores the .td file change but >>=20 >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >>=20 >> may use it. >>=20 >> I had accidentally used a SRC_CONF_ENV file that >> was of the first form. >>=20 >> So I've got a build going based on the 2nd form. . . >=20 > No such luck: same type of failure at the same point. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Dec-5, at 4:05 PM, Mark Millard = wrote: >=20 > On 2016-Dec-5, at 8:19 AM, Roman Divacky = wrote: >=20 >> Can you try this patch? >>=20 >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) >> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) >> @@ -2373,6 +2373,12 @@ >> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), >> "mftb $RT, $SPR", IIC_SprMFTB>; >>=20 >> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), >> + "mfpmr $RT, $PMRN", IIC_IntGeneral>; >> + >> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), >> + "mtpmr $PMRN, $RS", IIC_IntGeneral>; >> + >> // A pseudo-instruction used to implement the read of the 64-bit = cycle counter >> // on a 32-bit target. >> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in >=20 > Direct use of the patch (put into a file) was rejected: >=20 > # patch -p0 < llvmPPCInstrInfo_td.patch=20 > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > -------------------------- > Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... > patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, = (outs gprc:$RT), (ins i32imm:$SPR), >=20 > So I hand put in the extra lines. >=20 > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 > the MFTB line is at line number 2300 while your patch listed: >=20 > @@ -2373,6 +2373,12 @@ >=20 > My edit shows as: >=20 > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision = 309179) > +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2300,6 +2300,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; >=20 > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > + > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > // on a 32-bit target. > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in >=20 >=20 > Unfortunately the buildkernel still gets the same errors: > (This was tried after a kernel-toolchain .) >=20 > # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met= a > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp= c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g = -fno-omit-frame-pointer = -I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr= c/sys/GENERIC64vtsc-NODBG -mno-altivec -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-e > rror-unused-function -Wno-error-pointer-sign = -Wno-error-shift-negative-value -msoft-float -std=3Diso9899:1999 -c = /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o > CMD ctfconvert -L VERSION -g hwpmc_e500.o > CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc > TARGET hwpmc_e500.o > -- command output -- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: = unrecognized instruction mnemonic > mtpmr(PMR_PMGC0, pmgc0); > ^ > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > ^ > :1:2: note: instantiated into assembly here > mtpmr 400,3 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: = unrecognized instruction mnemonic > mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); > ^ > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > ^ > :1:2: note: instantiated into assembly here > mtpmr 400,3 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic > pmc_pmlc =3D mfpmr(PMR_PMLCa0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 10,144 > ^ > . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > Older content: >=20 > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: >> [Note: At present I can buildworld using WITH_LIB32=3D on >> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a >> minor variant of head -r309179 . That does not work for >> amd64 cross compiling to powerpc64 due to assembler >> notation rejections.] >>=20 >> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's >> clang 3.9.0 I get the following sorts of error >> reports, *even building on powerpc64* : >>=20 >> --- hwpmc_e500.o --- >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: = error: unrecognized instruction mnemonic >> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); >> ^ >> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' >> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ >> ^ >> :1:2: note: instantiated into assembly here >> mfpmr 3,400 >> ^ >> . . . >>=20 >> When I look up these instructions I find that they are not >> classic powerpc instructions: >> ( = http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd= f ) >>=20 >>> Whereas the classic architecture defines special-purpose registers = (SPRs) and >>> two instructions to access them (Move to Special-Purpose Register = (mtspr) and >>> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines >>> optional device control registers (DCRs) and mtdcr and mfdcr = instructions, and >>> the EIS-defined performance monitor APU defines performance monitor = registers >>> (PMRs) and mtpmr and mfpmr instructions, all based on models = provided by the >>> UISA. >>=20 >> . . . >>=20 >> Does this imply that clang 3.9.0 needs to support more instructions = when >> it is targeting FreeBSD for GENERIC64 based builds? (I include = GENERIC64 >> and then override some items for my build activity.) >>=20 >> If yes, then someone probably needs to make a list of what = instructions >> need to be present and have someone submit the list into llvm's = bugzilla >> and have the submittal listed in: >>=20 >> [META] Using Clang as the FreeBSD/ppc system compiler >>=20 >> (25780). >>=20 >>=20 >> If GENERIC64 does not need the likes of hwpmc_e500.o built then some >> work on the build environment to avoid GENERIC64 including things = with >> non-classic instruction use would appear to be needed. (No llvm >> involvement for this case.) I doubt this is the case as it would >> seem that the problem would reoccur when alternate KERNCONF's were >> in use instead that do require something like of hwpmc_e500.o to be >> built. >>=20 >>=20 >> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is = about >> this issue from the FreeBSD side of things. I just noticed the status >> of the specific instructions involved and also that the cross-build >> and on-powerpc64 build get the same result (unlike the recent >> WITH_LIB32=3D discovery). >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Thu Dec 8 03:31:56 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6526C6BF16 for ; Thu, 8 Dec 2016 03:31:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D57B5120D for ; Thu, 8 Dec 2016 03:31:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB83Vuj4012484 for ; Thu, 8 Dec 2016 03:31:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed) Date: Thu, 08 Dec 2016 03:31:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 03:31:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136 Bug ID: 215136 Summary: graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed) Product: Ports & Packages Version: Latest Hardware: i386 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: jbeich@FreeBSD.org CC: freebsd-toolchain@FreeBSD.org Created attachment 177777 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177777&action= =3Dedit src/util/camera_specs.cc (preprocessed, compressed) $ cd /usr/ports/graphics/colmap $ rm files/patch-src_util_CMakeLists.txt $ make [...] 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'src/util/camera_specs.cc'. 4. Running pass 'Value Propagation' on function '@_ZN6colmap21InitializeCameraSpecsEv' c++: error: unable to execute command: Abort trap c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: i386-unknown-freebsd10.1 Thread model: posix --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Dec 8 03:32:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 731FAC6BF72 for ; Thu, 8 Dec 2016 03:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 621431447 for ; Thu, 8 Dec 2016 03:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB83Womf037824 for ; Thu, 8 Dec 2016 03:32:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed) Date: Thu, 08 Dec 2016 03:32:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 03:32:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136 --- Comment #1 from Jan Beich (mail not working) --- Created attachment 177778 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177778&action= =3Dedit command line args (for clang 3.8+) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Dec 8 03:34:00 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADA4FC6BFF2 for ; Thu, 8 Dec 2016 03:34:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CBD614CD for ; Thu, 8 Dec 2016 03:34:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB83Y0ng068927 for ; Thu, 8 Dec 2016 03:34:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed) Date: Thu, 08 Dec 2016 03:34:00 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 03:34:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-ports-bugs@FreeBSD. |freebsd-toolchain@FreeBSD.o |org |rg CC|freebsd-toolchain@FreeBSD.o | |rg | --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Dec 8 05:52:51 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EDD8C6C0A9 for ; Thu, 8 Dec 2016 05:52:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (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 024B39C0 for ; Thu, 8 Dec 2016 05:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25494 invoked from network); 8 Dec 2016 05:52:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Dec 2016 05:52:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 08 Dec 2016 00:52:48 -0500 (EST) Received: (qmail 14381 invoked from network); 8 Dec 2016 05:52:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 05:52:48 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C0A77EC861A; Wed, 7 Dec 2016 21:52:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: Date: Wed, 7 Dec 2016 21:52:47 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 05:52:51 -0000 Top post of a FYI [head -r309656 powerpc64 context]: I commented out the one -mminimal-toc use in the modules and tried buildkernel again (cross build). It reached the end. But it dies immediately if I try to boot it after installing a copy. This was based on: # svnlite diff /usr/src/sys/modules/zfs/Makefile Index: /usr/src/sys/modules/zfs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/modules/zfs/Makefile (revision 309656) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,9 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS =20 -.if ${MACHINE_ARCH} =3D=3D "powerpc64" -CFLAGS+=3D-mminimal-toc -.endif +#.if ${MACHINE_ARCH} =3D=3D "powerpc64" +#CFLAGS+=3D-mminimal-toc +#.endif =20 .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 as well as your .td file patch. zfs is not in use in the configuration: it just uses ufs. I'll note that I had avoided 2.47 binutils variants based on reported issues in powerpc land (not that I know the details or the powerpc64 vs. powerpc vs. both status of the issues). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-7, at 4:11 PM, Mark Millard wrote: On 2016-Dec-7, at 11:00 AM, Roman Divacky wrote: > Can the compiler you built with the patch process this file: >=20 > typedef int register_t; > #define mtpmr(reg, val) = \ > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > #define mfpmr(reg) = \ > ( { register_t val; = \ > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > val; } ) >=20 > #define PMR_PMC0 16 >=20 > int foo() > { > return mfpmr(PMR_PMC0); > } >=20 >=20 > I can compile it just fine locally. Not sure why it wouldnt work in = your case. I separately had helped with testing for bugzilla 214902 and so had updated to head -r309656 so the context was different. But I figured out the .td file related issue on powerpc64. My means of forcing all the compiles that target powerpc64 to use -B to pick up the alternate toolchain (since the bootstrap binutils ld can fail) also forced the system compiler to be used instead of the bootstrapped clang. (The SRC_CONF_ENV file that I used had the text that forced this.) So my buildkernel was using an unpatched compiler when I tried kernel-toolchain then buildkernel. This was visible in the .meta file part of my report on the problem. It showed: > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ instead of having the path to the bootstrap compiler. It turns out that my amd64 cross build SRC_CONF_ENV file also had remnants of an experiment that also happened to force the system compiler to be used so it would have got the same behavior. Based on use of compilers that actually have your patch in them. . . Your patch worked fine to let the buildkernel reach the next problem: use of -mminimial-toc in a kernel module is made but is rejected for powerpc64. Sorry for the extra noise in reporting on your patch. Trying to find new things to report (future problems) by working around existing problems that are known but unfixed tends to have these sorts of interferences. Of course sometimes my workarounds might not be the best ones available. This stupid mistake is probably what is going on in at least one bugzilla report that I submitted: So I've likely got more to clean up. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material. . . On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote: > On 2016-Dec-5, at 5:16 PM, Mark Millard = wrote: >=20 >> Well it looks like: >>=20 >> WITHOUT_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >>=20 >> ignores the .td file change but >>=20 >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >>=20 >> may use it. >>=20 >> I had accidentally used a SRC_CONF_ENV file that >> was of the first form. >>=20 >> So I've got a build going based on the 2nd form. . . >=20 > No such luck: same type of failure at the same point. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Dec-5, at 4:05 PM, Mark Millard = wrote: >=20 > On 2016-Dec-5, at 8:19 AM, Roman Divacky = wrote: >=20 >> Can you try this patch? >>=20 >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) >> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) >> @@ -2373,6 +2373,12 @@ >> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), >> "mftb $RT, $SPR", IIC_SprMFTB>; >>=20 >> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), >> + "mfpmr $RT, $PMRN", IIC_IntGeneral>; >> + >> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), >> + "mtpmr $PMRN, $RS", IIC_IntGeneral>; >> + >> // A pseudo-instruction used to implement the read of the 64-bit = cycle counter >> // on a 32-bit target. >> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in >=20 > Direct use of the patch (put into a file) was rejected: >=20 > # patch -p0 < llvmPPCInstrInfo_td.patch=20 > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > -------------------------- > Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... > patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, = (outs gprc:$RT), (ins i32imm:$SPR), >=20 > So I hand put in the extra lines. >=20 > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 > the MFTB line is at line number 2300 while your patch listed: >=20 > @@ -2373,6 +2373,12 @@ >=20 > My edit shows as: >=20 > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision = 309179) > +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2300,6 +2300,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; >=20 > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > + > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > // on a 32-bit target. > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in >=20 >=20 > Unfortunately the buildkernel still gets the same errors: > (This was tried after a kernel-toolchain .) >=20 > # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met= a > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp= c64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr/src/sys -fno-common -g = -fno-omit-frame-pointer = -I/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/sr= c/sys/GENERIC64vtsc-NODBG -mno-altivec -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-e > rror-unused-function -Wno-error-pointer-sign = -Wno-error-shift-negative-value -msoft-float -std=3Diso9899:1999 -c = /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o > CMD ctfconvert -L VERSION -g hwpmc_e500.o > CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc > TARGET hwpmc_e500.o > -- command output -- > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 3,400 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: = unrecognized instruction mnemonic > mtpmr(PMR_PMGC0, pmgc0); > ^ > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > ^ > :1:2: note: instantiated into assembly here > mtpmr 400,3 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: = unrecognized instruction mnemonic > mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); > ^ > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > ^ > :1:2: note: instantiated into assembly here > mtpmr 400,3 > ^ > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic > pmc_pmlc =3D mfpmr(PMR_PMLCa0); > ^ > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > ^ > :1:2: note: instantiated into assembly here > mfpmr 10,144 > ^ > . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > Older content: >=20 > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: >> [Note: At present I can buildworld using WITH_LIB32=3D on >> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a >> minor variant of head -r309179 . That does not work for >> amd64 cross compiling to powerpc64 due to assembler >> notation rejections.] >>=20 >> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's >> clang 3.9.0 I get the following sorts of error >> reports, *even building on powerpc64* : >>=20 >> --- hwpmc_e500.o --- >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: = error: unrecognized instruction mnemonic >> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); >> ^ >> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' >> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ >> ^ >> :1:2: note: instantiated into assembly here >> mfpmr 3,400 >> ^ >> . . . >>=20 >> When I look up these instructions I find that they are not >> classic powerpc instructions: >> ( = http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPRMRM.pd= f ) >>=20 >>> Whereas the classic architecture defines special-purpose registers = (SPRs) and >>> two instructions to access them (Move to Special-Purpose Register = (mtspr) and >>> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines >>> optional device control registers (DCRs) and mtdcr and mfdcr = instructions, and >>> the EIS-defined performance monitor APU defines performance monitor = registers >>> (PMRs) and mtpmr and mfpmr instructions, all based on models = provided by the >>> UISA. >>=20 >> . . . >>=20 >> Does this imply that clang 3.9.0 needs to support more instructions = when >> it is targeting FreeBSD for GENERIC64 based builds? (I include = GENERIC64 >> and then override some items for my build activity.) >>=20 >> If yes, then someone probably needs to make a list of what = instructions >> need to be present and have someone submit the list into llvm's = bugzilla >> and have the submittal listed in: >>=20 >> [META] Using Clang as the FreeBSD/ppc system compiler >>=20 >> (25780). >>=20 >>=20 >> If GENERIC64 does not need the likes of hwpmc_e500.o built then some >> work on the build environment to avoid GENERIC64 including things = with >> non-classic instruction use would appear to be needed. (No llvm >> involvement for this case.) I doubt this is the case as it would >> seem that the problem would reoccur when alternate KERNCONF's were >> in use instead that do require something like of hwpmc_e500.o to be >> built. >>=20 >>=20 >> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is = about >> this issue from the FreeBSD side of things. I just noticed the status >> of the specific instructions involved and also that the cross-build >> and on-powerpc64 build get the same result (unlike the recent >> WITH_LIB32=3D discovery). >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Thu Dec 8 18:58:12 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14F0BC6DE98; Thu, 8 Dec 2016 18:58:12 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9EB182F; Thu, 8 Dec 2016 18:58:10 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 67BA7A35631; Thu, 8 Dec 2016 19:55:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1481223341; bh=2GbIgL5ZC8TjiVdj5Et8i5E/lPOPVBJp1AI+hlwlokw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=eFmLHLjMn6r7HElN9O3IbeYsnyYJN9JyT4W/j4R5QGz0YNfWbi3INK6/bM9yc1GiK LQRz3YRQHW1jyEShUWTj2IYXGgh66wwCLFrzT/INxTjglKllT4qIyPH8hoF5g/KOYf kTKLApU30Ril7fhTmIQkYWys/2VmPANvnsgvn3T4= Date: Thu, 8 Dec 2016 19:55:41 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20161208185541.GA33364@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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, 08 Dec 2016 18:58:12 -0000 Can you try to investigate why it dies? I am not convinced -mminimal-toc would result in a boot failure. I think the kernel would fail to link. On Wed, Dec 07, 2016 at 09:52:47PM -0800, Mark Millard wrote: > Top post of a FYI [head -r309656 powerpc64 context]: >=20 > I commented out the one -mminimal-toc use in the modules and tried > buildkernel again (cross build). >=20 > It reached the end. But it dies immediately if I try to > boot it after installing a copy. >=20 > This was based on: >=20 > # svnlite diff /usr/src/sys/modules/zfs/Makefile > Index: /usr/src/sys/modules/zfs/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/modules/zfs/Makefile (revision 309656) > +++ /usr/src/sys/modules/zfs/Makefile (working copy) > @@ -93,9 +93,9 @@ > CFLAGS+=3D-I${SUNW}/common > CFLAGS+=3D-DBUILDING_ZFS > =20 > -.if ${MACHINE_ARCH} =3D=3D "powerpc64" > -CFLAGS+=3D-mminimal-toc > -.endif > +#.if ${MACHINE_ARCH} =3D=3D "powerpc64" > +#CFLAGS+=3D-mminimal-toc > +#.endif > =20 > .ifdef ZFS_DEBUG > CFLAGS+=3D-DDEBUG=3D1 >=20 > as well as your .td file patch. >=20 > zfs is not in use in the configuration: it just > uses ufs. >=20 > I'll note that I had avoided 2.47 binutils variants > based on reported issues in powerpc land (not that > I know the details or the powerpc64 vs. powerpc vs. > both status of the issues). >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Dec-7, at 4:11 PM, Mark Millard wrote: >=20 > On 2016-Dec-7, at 11:00 AM, Roman Divacky wrote: >=20 > > Can the compiler you built with the patch process this file: > >=20 > > typedef int register_t; > > #define mtpmr(reg, val) = \ > > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > > #define mfpmr(reg) = \ > > ( { register_t val; \ > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > > val; } ) > >=20 > > #define PMR_PMC0 16 > >=20 > > int foo() > > { > > return mfpmr(PMR_PMC0); > > } > >=20 > >=20 > > I can compile it just fine locally. Not sure why it wouldnt work in you= r case. >=20 > I separately had helped with testing for bugzilla 214902 > and so had updated to head -r309656 so the context was > different. >=20 > But I figured out the .td file related issue on powerpc64. >=20 > My means of forcing all the compiles that target powerpc64 > to use -B to pick up the alternate toolchain (since the > bootstrap binutils ld can fail) also forced the system > compiler to be used instead of the bootstrapped clang. > (The SRC_CONF_ENV file that I used had the text that > forced this.) >=20 > So my buildkernel was using an unpatched compiler when > I tried kernel-toolchain then buildkernel. >=20 > This was visible in the .meta file part of my report on the > problem. It showed: >=20 > > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ >=20 >=20 > instead of having the path to the bootstrap compiler. >=20 > It turns out that my amd64 cross build SRC_CONF_ENV file > also had remnants of an experiment that also happened to > force the system compiler to be used so it would have got > the same behavior. >=20 > Based on use of compilers that actually have your > patch in them. . . >=20 > Your patch worked fine to let the buildkernel reach > the next problem: use of -mminimial-toc in a kernel > module is made but is rejected for powerpc64. >=20 > Sorry for the extra noise in reporting on your patch. >=20 >=20 > Trying to find new things to report (future problems) > by working around existing problems that are known but > unfixed tends to have these sorts of interferences. Of > course sometimes my workarounds might not be the best > ones available. >=20 > This stupid mistake is probably what is going on in > at least one bugzilla report that I submitted: So > I've likely got more to clean up. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > Older material. . . >=20 > On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote: > > On 2016-Dec-5, at 5:16 PM, Mark Millard wrote: > >=20 > >> Well it looks like: > >>=20 > >> WITHOUT_CROSS_COMPILER=3D > >> WITH_SYSTEM_COMPILER=3D > >>=20 > >> ignores the .td file change but > >>=20 > >> WITH_CROSS_COMPILER=3D > >> WITHOUT_SYSTEM_COMPILER=3D > >>=20 > >> may use it. > >>=20 > >> I had accidentally used a SRC_CONF_ENV file that > >> was of the first form. > >>=20 > >> So I've got a build going based on the 2nd form. . . > >=20 > > No such luck: same type of failure at the same point. > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net > >=20 > > On 2016-Dec-5, at 4:05 PM, Mark Millard wrote: > >=20 > > On 2016-Dec-5, at 8:19 AM, Roman Divacky wrote: > >=20 > >> Can you try this patch? > >>=20 > >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > >> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > >> @@ -2373,6 +2373,12 @@ > >> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > >> "mftb $RT, $SPR", IIC_SprMFTB>; > >>=20 > >> +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > >> + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > >> + > >> +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > >> + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > >> + > >> // A pseudo-instruction used to implement the read of the 64-bit cycle= counter > >> // on a 32-bit target. > >> let hasSideEffects =3D 1, usesCustomInserter =3D 1 in > >=20 > > Direct use of the patch (put into a file) was rejected: > >=20 > > # patch -p0 < llvmPPCInstrInfo_td.patch=20 > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > -------------------------- > > Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... > > patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, (o= uts gprc:$RT), (ins i32imm:$SPR), > >=20 > > So I hand put in the extra lines. > >=20 > > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 > > the MFTB line is at line number 2300 while your patch listed: > >=20 > > @@ -2373,6 +2373,12 @@ > >=20 > > My edit shows as: > >=20 > > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 309179) > > +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > @@ -2300,6 +2300,12 @@ > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > "mftb $RT, $SPR", IIC_SprMFTB>; > >=20 > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > > + > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > > + > > // A pseudo-instruction used to implement the read of the 64-bit cycle = counter > > // on a 32-bit target. > > let hasSideEffects =3D 1, usesCustomInserter =3D 1 in > >=20 > >=20 > > Unfortunately the buildkernel still gets the same errors: > > (This was tried after a kernel-toolchain .) > >=20 > > # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerp= c.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwp= mc/hwpmc_e500.o.meta > > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target powerpc= 64-unknown-freebsd12.0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils= _kernel/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -= O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KE= RNEL_OPTION_HEADERS -include /usr/obj/powerpc64vtsc_clang_altbinutils_kerne= l/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr= /src/sys -fno-common -g -fno-omit-frame-pointer -I/usr/obj/powerpc64vtsc_cl= ang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG -= mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredu= ndant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__= freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-err= or-parentheses-equality -Wno-e > > rror-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-= value -msoft-float -std=3Diso9899:1999 -c /usr/src/sys/modules/hwpmc/../.= =2E/dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o > > CMD ctfconvert -L VERSION -g hwpmc_e500.o > > CWD /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/u= sr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc > > TARGET hwpmc_e500.o > > -- command output -- > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > > ^ > > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > > ^ > > :1:2: note: instantiated into assembly here > > mfpmr 3,400 > > ^ > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: u= nrecognized instruction mnemonic > > mtpmr(PMR_PMGC0, pmgc0); > > ^ > > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > > ^ > > :1:2: note: instantiated into assembly here > > mtpmr 400,3 > > ^ > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: u= nrecognized instruction mnemonic > > mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); > > ^ > > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > > ^ > > :1:2: note: instantiated into assembly here > > mtpmr 400,3 > > ^ > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic > > pmc_pmlc =3D mfpmr(PMR_PMLCa0); > > ^ > > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > > ^ > > :1:2: note: instantiated into assembly here > > mfpmr 10,144 > > ^ > > . . . > >=20 > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net > >=20 > > Older content: > >=20 > > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > >> [Note: At present I can buildworld using WITH_LIB32=3D on > >> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a > >> minor variant of head -r309179 . That does not work for > >> amd64 cross compiling to powerpc64 due to assembler > >> notation rejections.] > >>=20 > >> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's > >> clang 3.9.0 I get the following sorts of error > >> reports, *even building on powerpc64* : > >>=20 > >> --- hwpmc_e500.o --- > >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error:= unrecognized instruction mnemonic > >> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > >> ^ > >> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > >> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > >> ^ > >> :1:2: note: instantiated into assembly here > >> mfpmr 3,400 > >> ^ > >> . . . > >>=20 > >> When I look up these instructions I find that they are not > >> classic powerpc instructions: > >> ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPR= MRM.pdf ) > >>=20 > >>> Whereas the classic architecture defines special-purpose registers (S= PRs) and > >>> two instructions to access them (Move to Special-Purpose Register (mt= spr) and > >>> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines > >>> optional device control registers (DCRs) and mtdcr and mfdcr instruct= ions, and > >>> the EIS-defined performance monitor APU defines performance monitor r= egisters > >>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided= by the > >>> UISA. > >>=20 > >> . . . > >>=20 > >> Does this imply that clang 3.9.0 needs to support more instructions wh= en > >> it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC= 64 > >> and then override some items for my build activity.) > >>=20 > >> If yes, then someone probably needs to make a list of what instructions > >> need to be present and have someone submit the list into llvm's bugzil= la > >> and have the submittal listed in: > >>=20 > >> [META] Using Clang as the FreeBSD/ppc system compiler > >>=20 > >> (25780). > >>=20 > >>=20 > >> If GENERIC64 does not need the likes of hwpmc_e500.o built then some > >> work on the build environment to avoid GENERIC64 including things with > >> non-classic instruction use would appear to be needed. (No llvm > >> involvement for this case.) I doubt this is the case as it would > >> seem that the problem would reoccur when alternate KERNCONF's were > >> in use instead that do require something like of hwpmc_e500.o to be > >> built. > >>=20 > >>=20 > >> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is ab= out > >> this issue from the FreeBSD side of things. I just noticed the status > >> of the specific instructions involved and also that the cross-build > >> and on-powerpc64 build get the same result (unlike the recent > >> WITH_LIB32=3D discovery). > >>=20 > >> =3D=3D=3D > >> Mark Millard > >> markmi at dsl-only.net > >=20 > >=20 > > _______________________________________________ > > freebsd-ppc@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Thu Dec 8 21:02:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1C31C6EAE9 for ; Thu, 8 Dec 2016 21:02:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90C97A70 for ; Thu, 8 Dec 2016 21:02:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB8L2llD026443 for ; Thu, 8 Dec 2016 21:02:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215136] graphics/colmap: clang -O2 runs out of memory on i386 then aborts (i.e. not killed) Date: Thu, 08 Dec 2016 21:02:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:02:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215136 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | Status|New |In Progress --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Dec 8 22:10:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF32C6EF26 for ; Thu, 8 Dec 2016 22:10:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-71.reflexion.net [208.70.210.71]) (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 57E94E2E for ; Thu, 8 Dec 2016 22:10:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6627 invoked from network); 8 Dec 2016 22:03:59 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Dec 2016 22:03:59 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 08 Dec 2016 17:03:59 -0500 (EST) Received: (qmail 22978 invoked from network); 8 Dec 2016 22:03:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 22:03:59 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id CA579EC9142; Thu, 8 Dec 2016 14:03:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <20161208185541.GA33364@vlakno.cz> Date: Thu, 8 Dec 2016 14:03:58 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:10:41 -0000 [I have dropped the patch related information and just have failing-boot related information here.] On 2016-Dec-8, at 10:55 AM, Roman Divacky wrote: > Can you try to investigate why it dies? I am not convinced = -mminimal-toc > would result in a boot failure. I think the kernel would fail to link. I give information for both devel/powerpc64-binutils based and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different. For using 2.25.1 of devel/powerpc64-binutils (a cross build): (from camera image of screen) . . . (omitted material) . . . Type '?' for a list of commands, 'help' for more detailed help. OK unload OK boot ker390 /boot/ker390/kernel data=3D0xf851a8+0x42dd98 = syms=3D[0x8+0xd6848+0x8+0xf1137] /boot/entropy size=3D0x1000 Booting. . . Kernel entry at 0x100160 Invalid memory access at %SSR0: 00000000.001001b0 = %SRR1:90000000.00003030 Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 . . . (omitted material) . . . ok 0 > The only options at this point are: mac-boot shut-down =46rom objdump for the above failing boot but with notes added: (Note: booting xtoolchain kernel starts at 0000000000100120 instead; relative offsets are unchanged and the code is mostly the same.) Disassembly of section .text: 0000000000100160 <.__start> mfmsr r20 0000000000100164 <.__start+0x4> li r21,1 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0 000000000010016c <.__start+0xc> mtmsrd r20 0000000000100170 <.__start+0x10> isync 0000000000100174 <.__start+0x14> nop 0000000000100178 <.__start+0x18> b 0000000000100180 = <.__start+0x20> 000000000010017c <.__start+0x1c> nop 0000000000100180 <.__start+0x20> nop 0000000000100184 <.__start+0x24> bl 0000000000100190 = <.__start+0x30> 0000000000100188 <.__start+0x28> .long 0x0 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20 booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D = note 0000000000100190 <.__start+0x30> mflr r2 0000000000100194 <.__start+0x34> ld r1,0(r2) 0000000000100198 <.__start+0x38> add r2,r1,r2 000000000010019c <.__start+0x3c> ld r31,-32768(r2) 00000000001001a0 <.__start+0x40> subf r31,r31,r2 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D = !!!!! booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D = !!!!! 00000000001001a8 <.__start+0x48> addi r1,r1,16288 00000000001001ac <.__start+0x4c> add r1,r1,r31 00000000001001b0 <.__start+0x50> std r3,48(r1) SRR0 points at the above instruction (I stopped comparing to the booting xtoolchain based code after this.) 00000000001001b4 <.__start+0x54> std r4,56(r1) 00000000001001b8 <.__start+0x58> std r5,64(r1) 00000000001001bc <.__start+0x5c> std r6,72(r1) 00000000001001c0 <.__start+0x60> bl 00000000001001cc = <.__start+0x6c> 00000000001001c4 <.__start+0x64> .long 0x0 00000000001001c8 <.__start+0x68> .long 0xf84ed4 00000000001001cc <.__start+0x6c> mflr r3 00000000001001d0 <.__start+0x70> ld r4,0(r3) 00000000001001d4 <.__start+0x74> add r3,r4,r3 00000000001001d8 <.__start+0x78> mr r4,r31 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc = <.elf_reloc_self> 00000000001001e0 <.__start+0x80> nop 00000000001001e4 <.__start+0x84> ld r3,48(r1) 00000000001001e8 <.__start+0x88> ld r4,56(r1) 00000000001001ec <.__start+0x8c> ld r5,64(r1) 00000000001001f0 <.__start+0x90> ld r6,72(r1) 00000000001001f4 <.__start+0x94> mr r4,r2 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 = <.powerpc_init> 00000000001001fc <.__start+0x9c> nop 0000000000100200 <.__start+0xa0> mr r1,r3 0000000000100204 <.__start+0xa4> li r3,0 0000000000100208 <.__start+0xa8> std r3,0(r1) 000000000010020c <.__start+0xac> bl 00000000005c4af8 <.mi_startup> 0000000000100210 <.__start+0xb0> nop 0000000000100214 <.__start+0xb4> b 0000000000100214 = <.__start+0xb4> For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build): (completes for buildkernel; fails for buildworld) . . . (omitted material) . . . Type '?' for a list of commands, 'help' for more detailed help. OK unload OK boot ker39a /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 = syms=3D[0x8+0xd6860+0x8+0xf1193] /boot/entropy size=3D0x1000 Booting. . . Kernel entry at 0x100160 Invalid memory access at %SSR0: 00000000.00000000 = %SRR1:10000000.00081000 Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 . . . (omitted material) . . . ok 0 > The only options at this point are: mac-boot shut-down The problem here is a different code order and a matching wrong start address that does not track the difference. (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity exists in the start routine as well. Disassembly of section .text: 0000000000100160 <.__start-0x2030> std r2,40(r1) 0000000000100164 <.__start-0x202c> addis r2,r2,1 0000000000100168 <.__start-0x2028> addi r2,r2,-8 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 = <.cpu_switch> 0000000000100170 <.__start-0x2020> std r2,40(r1) 0000000000100174 <.__start-0x201c> addis r2,r2,1 0000000000100178 <.__start-0x2018> addi r2,r2,-8 000000000010017c <.__start-0x2014> b 0000000000ade6c8 = <.sf_buf_alloc> 0000000000100180 <.__start-0x2010> std r2,40(r1) 0000000000100184 <.__start-0x200c> addis r2,r2,1 0000000000100188 <.__start-0x2008> addi r2,r2,-8 000000000010018c <.__start-0x2004> b 0000000000a83f78 = <.vm_fault_hold> 0000000000100190 <.__start-0x2000> std r2,40(r1) 0000000000100194 <.__start-0x1ffc> addis r2,r2,1 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 = <.fill_regs32> 00000000001001a0 <.__start-0x1ff0> std r2,40(r1) 00000000001001a4 <.__start-0x1fec> addis r2,r2,1 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 = <.casueword32> 00000000001001b0 <.__start-0x1fe0> std r2,40(r1) 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 = <.kmap_free_wakeup> . . . 0000000000102190 <.__start> mfmsr r20 0000000000102194 <.__start+0x4> li r21,1 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0 000000000010219c <.__start+0xc> mtmsrd r20 00000000001021a0 <.__start+0x10> isync 00000000001021a4 <.__start+0x14> nop 00000000001021a8 <.__start+0x18> b 00000000001021b0 = <.__start+0x20> 00000000001021ac <.__start+0x1c> nop 00000000001021b0 <.__start+0x20> nop 00000000001021b4 <.__start+0x24> bl 00000000001021c0 = <.__start+0x30> 00000000001021b8 <.__start+0x28> .long 0x0 00000000001021bc <.__start+0x2c> .long 0xfc8e48 00000000001021c0 <.__start+0x30> mflr r2 00000000001021c4 <.__start+0x34> ld r1,0(r2) 00000000001021c8 <.__start+0x38> add r2,r1,r2 00000000001021cc <.__start+0x3c> ld r31,-32768(r2) 00000000001021d0 <.__start+0x40> subf r31,r31,r2 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. = -32760 oddity!!! 00000000001021d8 <.__start+0x48> addi r1,r1,16288 00000000001021dc <.__start+0x4c> add r1,r1,r31 00000000001021e0 <.__start+0x50> std r3,48(r1) 00000000001021e4 <.__start+0x54> std r4,56(r1) 00000000001021e8 <.__start+0x58> std r5,64(r1) 00000000001021ec <.__start+0x5c> std r6,72(r1) 00000000001021f0 <.__start+0x60> bl 00000000001021fc = <.__start+0x6c> 00000000001021f4 <.__start+0x64> .long 0x0 00000000001021f8 <.__start+0x68> .long 0xfd4014 00000000001021fc <.__start+0x6c> mflr r3 0000000000102200 <.__start+0x70> ld r4,0(r3) 0000000000102204 <.__start+0x74> add r3,r4,r3 0000000000102208 <.__start+0x78> mr r4,r31 000000000010220c <.__start+0x7c> bl 0000000000101a20 0000000000102210 <.__start+0x80> ld r2,40(r1) 0000000000102214 <.__start+0x84> ld r3,48(r1) 0000000000102218 <.__start+0x88> ld r4,56(r1) 000000000010221c <.__start+0x8c> ld r5,64(r1) 0000000000102220 <.__start+0x90> ld r6,72(r1) 0000000000102224 <.__start+0x94> mr r4,r2 0000000000102228 <.__start+0x98> bl 00000000001019a0 000000000010222c <.__start+0x9c> ld r2,40(r1) 0000000000102230 <.__start+0xa0> mr r1,r3 0000000000102234 <.__start+0xa4> li r3,0 0000000000102238 <.__start+0xa8> std r3,0(r1) 000000000010223c <.__start+0xac> bl 00000000005c6b28 <.mi_startup> 0000000000102240 <.__start+0xb0> nop 0000000000102244 <.__start+0xb4> b 0000000000102244 = <.__start+0xb4> Who is most appropriate to send such information to for powerpc64? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Dec 8 22:17:28 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3905C6D13E; Thu, 8 Dec 2016 22:17:28 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6E710115A; Thu, 8 Dec 2016 22:17:27 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 6DA4DA35642; Thu, 8 Dec 2016 23:14:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1481235292; bh=AEbR7wvCJ6r5zGGvCrm0og9sNSK7q6/6kCHYiacjU8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HIsrZ7BW1vK26fETY+xxXCgMO0gszEND8xE1DwvMLMc/9jSn+YTiar/GMxZROSXVx Q4p5rj4TbzX4ZBT9zPtDhskcK6eEpBE6Eias6WjcfYrlCGGJO+LP+M3e+quFOnTWuM eowpiP9+ONl4MWqJyRKaECDqcq34jf8tdKperq4s= Date: Thu, 8 Dec 2016 23:14:52 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML , nwhitehorn@freebsd.org Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20161208221452.GA42380@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-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, 08 Dec 2016 22:17:28 -0000 I believe the code comes from sys/powerpc/aim/locore64.S and if you compare the different values from the disssembly with the .S code you can see it's __tocbase and TOC_REF(). I wonder if the assembly has the -mminimal-toc knowledge hardcoded in somehow. I am not sure what expectations the locore64.S has about the kernel layout that we're probably breaking. I've CCed Nathan Whitehorn. Nathan, can you take a look please? Thanks, Roman On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote: > [I have dropped the patch related information and just have > failing-boot related information here.] > > On 2016-Dec-8, at 10:55 AM, Roman Divacky wrote: > > > Can you try to investigate why it dies? I am not convinced -mminimal-toc > > would result in a boot failure. I think the kernel would fail to link. > > I give information for both devel/powerpc64-binutils based > and for WITH_BINUTILS_BOOTSTRAP= based. They are different. > > For using 2.25.1 of devel/powerpc64-binutils (a cross build): > (from camera image of screen) > > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker390 > /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137] > /boot/entropy size=0x1000 > Booting. . . > Kernel entry at 0x100160 > > Invalid memory access at %SSR0: 00000000.001001b0 %SRR1:90000000.00003030 > > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > > > The only options at this point are: > > mac-boot > shut-down > > > From objdump for the above failing boot > but with notes added: > (Note: booting xtoolchain kernel starts at > 0000000000100120 instead; relative > offsets are unchanged and the code > is mostly the same.) > > Disassembly of section .text: > 0000000000100160 <.__start> mfmsr r20 > 0000000000100164 <.__start+0x4> li r21,1 > 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010016c <.__start+0xc> mtmsrd r20 > 0000000000100170 <.__start+0x10> isync > 0000000000100174 <.__start+0x14> nop > 0000000000100178 <.__start+0x18> b 0000000000100180 <.__start+0x20> > 000000000010017c <.__start+0x1c> nop > 0000000000100180 <.__start+0x20> nop > 0000000000100184 <.__start+0x24> bl 0000000000100190 <.__start+0x30> > 0000000000100188 <.__start+0x28> .long 0x0 > 000000000010018c <.__start+0x2c> .long 0xf8ce78 > booting xtoolchain based kernel has: 0xfebeb8 above <<<=== note > 0000000000100190 <.__start+0x30> mflr r2 > 0000000000100194 <.__start+0x34> ld r1,0(r2) > 0000000000100198 <.__start+0x38> add r2,r1,r2 > 000000000010019c <.__start+0x3c> ld r31,-32768(r2) > 00000000001001a0 <.__start+0x40> subf r31,r31,r2 > 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=== !!!!! > booting xtoolchain based kernel has: r1,-32760(r2) above <<<=== !!!!! > 00000000001001a8 <.__start+0x48> addi r1,r1,16288 > 00000000001001ac <.__start+0x4c> add r1,r1,r31 > 00000000001001b0 <.__start+0x50> std r3,48(r1) > SRR0 points at the above instruction > (I stopped comparing to the booting xtoolchain > based code after this.) > 00000000001001b4 <.__start+0x54> std r4,56(r1) > 00000000001001b8 <.__start+0x58> std r5,64(r1) > 00000000001001bc <.__start+0x5c> std r6,72(r1) > 00000000001001c0 <.__start+0x60> bl 00000000001001cc <.__start+0x6c> > 00000000001001c4 <.__start+0x64> .long 0x0 > 00000000001001c8 <.__start+0x68> .long 0xf84ed4 > 00000000001001cc <.__start+0x6c> mflr r3 > 00000000001001d0 <.__start+0x70> ld r4,0(r3) > 00000000001001d4 <.__start+0x74> add r3,r4,r3 > 00000000001001d8 <.__start+0x78> mr r4,r31 > 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc <.elf_reloc_self> > 00000000001001e0 <.__start+0x80> nop > 00000000001001e4 <.__start+0x84> ld r3,48(r1) > 00000000001001e8 <.__start+0x88> ld r4,56(r1) > 00000000001001ec <.__start+0x8c> ld r5,64(r1) > 00000000001001f0 <.__start+0x90> ld r6,72(r1) > 00000000001001f4 <.__start+0x94> mr r4,r2 > 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 <.powerpc_init> > 00000000001001fc <.__start+0x9c> nop > 0000000000100200 <.__start+0xa0> mr r1,r3 > 0000000000100204 <.__start+0xa4> li r3,0 > 0000000000100208 <.__start+0xa8> std r3,0(r1) > 000000000010020c <.__start+0xac> bl 00000000005c4af8 <.mi_startup> > 0000000000100210 <.__start+0xb0> nop > 0000000000100214 <.__start+0xb4> b 0000000000100214 <.__start+0xb4> > > > > For using WITH_BINUTILS_BOOTSTRAP= based binutils (a cross build): > (completes for buildkernel; fails for buildworld) > > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker39a > /boot/ker39a/kernel data=0xfd6318+0x42dda8 syms=[0x8+0xd6860+0x8+0xf1193] > /boot/entropy size=0x1000 > Booting. . . > Kernel entry at 0x100160 > > Invalid memory access at %SSR0: 00000000.00000000 %SRR1:10000000.00081000 > > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > > > The only options at this point are: > > mac-boot > shut-down > > The problem here is a different code order and a matching > wrong start address that does not track the difference. > (From objdump.) Note: the same 0(r2) vs. -32760(r2) oddity > exists in the start routine as well. > > Disassembly of section .text: > 0000000000100160 <.__start-0x2030> std r2,40(r1) > 0000000000100164 <.__start-0x202c> addis r2,r2,1 > 0000000000100168 <.__start-0x2028> addi r2,r2,-8 > 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 <.cpu_switch> > 0000000000100170 <.__start-0x2020> std r2,40(r1) > 0000000000100174 <.__start-0x201c> addis r2,r2,1 > 0000000000100178 <.__start-0x2018> addi r2,r2,-8 > 000000000010017c <.__start-0x2014> b 0000000000ade6c8 <.sf_buf_alloc> > 0000000000100180 <.__start-0x2010> std r2,40(r1) > 0000000000100184 <.__start-0x200c> addis r2,r2,1 > 0000000000100188 <.__start-0x2008> addi r2,r2,-8 > 000000000010018c <.__start-0x2004> b 0000000000a83f78 <.vm_fault_hold> > 0000000000100190 <.__start-0x2000> std r2,40(r1) > 0000000000100194 <.__start-0x1ffc> addis r2,r2,1 > 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8 > 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 <.fill_regs32> > 00000000001001a0 <.__start-0x1ff0> std r2,40(r1) > 00000000001001a4 <.__start-0x1fec> addis r2,r2,1 > 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8 > 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 <.casueword32> > 00000000001001b0 <.__start-0x1fe0> std r2,40(r1) > 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1 > 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8 > 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 <.kmap_free_wakeup> > . . . > 0000000000102190 <.__start> mfmsr r20 > 0000000000102194 <.__start+0x4> li r21,1 > 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010219c <.__start+0xc> mtmsrd r20 > 00000000001021a0 <.__start+0x10> isync > 00000000001021a4 <.__start+0x14> nop > 00000000001021a8 <.__start+0x18> b 00000000001021b0 <.__start+0x20> > 00000000001021ac <.__start+0x1c> nop > 00000000001021b0 <.__start+0x20> nop > 00000000001021b4 <.__start+0x24> bl 00000000001021c0 <.__start+0x30> > 00000000001021b8 <.__start+0x28> .long 0x0 > 00000000001021bc <.__start+0x2c> .long 0xfc8e48 > 00000000001021c0 <.__start+0x30> mflr r2 > 00000000001021c4 <.__start+0x34> ld r1,0(r2) > 00000000001021c8 <.__start+0x38> add r2,r1,r2 > 00000000001021cc <.__start+0x3c> ld r31,-32768(r2) > 00000000001021d0 <.__start+0x40> subf r31,r31,r2 > 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. -32760 oddity!!! > 00000000001021d8 <.__start+0x48> addi r1,r1,16288 > 00000000001021dc <.__start+0x4c> add r1,r1,r31 > 00000000001021e0 <.__start+0x50> std r3,48(r1) > 00000000001021e4 <.__start+0x54> std r4,56(r1) > 00000000001021e8 <.__start+0x58> std r5,64(r1) > 00000000001021ec <.__start+0x5c> std r6,72(r1) > 00000000001021f0 <.__start+0x60> bl 00000000001021fc <.__start+0x6c> > 00000000001021f4 <.__start+0x64> .long 0x0 > 00000000001021f8 <.__start+0x68> .long 0xfd4014 > 00000000001021fc <.__start+0x6c> mflr r3 > 0000000000102200 <.__start+0x70> ld r4,0(r3) > 0000000000102204 <.__start+0x74> add r3,r4,r3 > 0000000000102208 <.__start+0x78> mr r4,r31 > 000000000010220c <.__start+0x7c> bl 0000000000101a20 > 0000000000102210 <.__start+0x80> ld r2,40(r1) > 0000000000102214 <.__start+0x84> ld r3,48(r1) > 0000000000102218 <.__start+0x88> ld r4,56(r1) > 000000000010221c <.__start+0x8c> ld r5,64(r1) > 0000000000102220 <.__start+0x90> ld r6,72(r1) > 0000000000102224 <.__start+0x94> mr r4,r2 > 0000000000102228 <.__start+0x98> bl 00000000001019a0 > 000000000010222c <.__start+0x9c> ld r2,40(r1) > 0000000000102230 <.__start+0xa0> mr r1,r3 > 0000000000102234 <.__start+0xa4> li r3,0 > 0000000000102238 <.__start+0xa8> std r3,0(r1) > 000000000010223c <.__start+0xac> bl 00000000005c6b28 <.mi_startup> > 0000000000102240 <.__start+0xb0> nop > 0000000000102244 <.__start+0xb4> b 0000000000102244 <.__start+0xb4> > > > Who is most appropriate to send such information to for powerpc64? > > === > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Dec 8 23:01:32 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F7FDC6E01F for ; Thu, 8 Dec 2016 23:01:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (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 D4CF3950 for ; Thu, 8 Dec 2016 23:01:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32516 invoked from network); 8 Dec 2016 23:01:30 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 Dec 2016 23:01:30 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 08 Dec 2016 18:01:37 -0500 (EST) Received: (qmail 20397 invoked from network); 8 Dec 2016 23:01:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 23:01:37 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 260CDEC900F; Thu, 8 Dec 2016 15:01:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <20161208221452.GA42380@vlakno.cz> Date: Thu, 8 Dec 2016 15:01:28 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> To: Roman Divacky , Nathan Whitehorn X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 23:01:32 -0000 On 2016-Dec-8, at 2:14 PM, Roman Divacky wrote: > I believe the code comes from sys/powerpc/aim/locore64.S and if you = compare > the different values from the disssembly with the .S code you can see > it's __tocbase and TOC_REF(). >=20 > I wonder if the assembly has the -mminimal-toc knowledge hardcoded in = somehow. > I am not sure what expectations the locore64.S has about the kernel = layout that > we're probably breaking. >=20 > I've CCed Nathan Whitehorn. Nathan, can you take a look please? >=20 > Thanks, Roman For Nathan's reference about the context: I got to the point of having a clang 3.9.0 buildkernel finish for targeting powerpc64. But it does not boot. I'm working from head -r309656 with the following patches: (ignoring my usual PowerMac G5 powerpc64 booting hack related materials that I've had in place for a long time) # svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td = (revision 309656) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) @@ -2300,6 +2300,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; =20 +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle = counter // on a 32-bit target. let hasSideEffects =3D 1, usesCustomInserter =3D 1 in (Roman Divacky supplied the above patch.) # svnlite diff /usr/src/sys/modules/zfs/Makefile Index: /usr/src/sys/modules/zfs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/modules/zfs/Makefile (revision 309656) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,9 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS =20 -.if ${MACHINE_ARCH} =3D=3D "powerpc64" -CFLAGS+=3D-mminimal-toc -.endif +#.if ${MACHINE_ARCH} =3D=3D "powerpc64" +#CFLAGS+=3D-mminimal-toc +#.endif =20 .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 This last just avoids that clang 3.9.0 for targeting powerpc64 rejects the -mminimal-toc command line option. It being missing did not cause the buildkernel to stop. Note: I have booted with clang 3.9.0 based buildworld materials. (But C++ exception handling is still messed up so code dependent on C++ exceptions happening needs to be avoided.) I've had to avoid both WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants of devel/powerpc64-binutils or devel/binutils: I use older 2.25.1 devel/powerpc64-binutils or devel/binutils (on the powerpc64 itself). However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like binutils do not end up with ld failing and buildkernel appears to complete. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material: On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote: > [I have dropped the patch related information and just have > failing-boot related information here.] >=20 > On 2016-Dec-8, at 10:55 AM, Roman Divacky = wrote: >=20 >> Can you try to investigate why it dies? I am not convinced = -mminimal-toc >> would result in a boot failure. I think the kernel would fail to = link. >=20 > I give information for both devel/powerpc64-binutils based > and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different. >=20 > For using 2.25.1 of devel/powerpc64-binutils (a cross build): > (from camera image of screen) >=20 > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker390 > /boot/ker390/kernel data=3D0xf851a8+0x42dd98 = syms=3D[0x8+0xd6848+0x8+0xf1137] > /boot/entropy size=3D0x1000 > Booting. . . > Kernel entry at 0x100160 >=20 > Invalid memory access at %SSR0: 00000000.001001b0 = %SRR1:90000000.00003030 >=20 > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > >=20 > The only options at this point are: >=20 > mac-boot > shut-down >=20 >=20 > =46rom objdump for the above failing boot > but with notes added: > (Note: booting xtoolchain kernel starts at > 0000000000100120 instead; relative > offsets are unchanged and the code > is mostly the same.) >=20 > Disassembly of section .text: > 0000000000100160 <.__start> mfmsr r20 > 0000000000100164 <.__start+0x4> li r21,1 > 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010016c <.__start+0xc> mtmsrd r20 > 0000000000100170 <.__start+0x10> isync > 0000000000100174 <.__start+0x14> nop > 0000000000100178 <.__start+0x18> b 0000000000100180 = <.__start+0x20> > 000000000010017c <.__start+0x1c> nop > 0000000000100180 <.__start+0x20> nop > 0000000000100184 <.__start+0x24> bl 0000000000100190 = <.__start+0x30> > 0000000000100188 <.__start+0x28> .long 0x0 > 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20 > booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D = note > 0000000000100190 <.__start+0x30> mflr r2 > 0000000000100194 <.__start+0x34> ld r1,0(r2) > 0000000000100198 <.__start+0x38> add r2,r1,r2 > 000000000010019c <.__start+0x3c> ld r31,-32768(r2) > 00000000001001a0 <.__start+0x40> subf r31,r31,r2 > 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D= !!!!! > booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D= !!!!! > 00000000001001a8 <.__start+0x48> addi r1,r1,16288 > 00000000001001ac <.__start+0x4c> add r1,r1,r31 > 00000000001001b0 <.__start+0x50> std r3,48(r1) > SRR0 points at the above instruction > (I stopped comparing to the booting xtoolchain > based code after this.) > 00000000001001b4 <.__start+0x54> std r4,56(r1) > 00000000001001b8 <.__start+0x58> std r5,64(r1) > 00000000001001bc <.__start+0x5c> std r6,72(r1) > 00000000001001c0 <.__start+0x60> bl 00000000001001cc = <.__start+0x6c> > 00000000001001c4 <.__start+0x64> .long 0x0 > 00000000001001c8 <.__start+0x68> .long 0xf84ed4 > 00000000001001cc <.__start+0x6c> mflr r3 > 00000000001001d0 <.__start+0x70> ld r4,0(r3) > 00000000001001d4 <.__start+0x74> add r3,r4,r3 > 00000000001001d8 <.__start+0x78> mr r4,r31 > 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc = <.elf_reloc_self> > 00000000001001e0 <.__start+0x80> nop > 00000000001001e4 <.__start+0x84> ld r3,48(r1) > 00000000001001e8 <.__start+0x88> ld r4,56(r1) > 00000000001001ec <.__start+0x8c> ld r5,64(r1) > 00000000001001f0 <.__start+0x90> ld r6,72(r1) > 00000000001001f4 <.__start+0x94> mr r4,r2 > 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 = <.powerpc_init> > 00000000001001fc <.__start+0x9c> nop > 0000000000100200 <.__start+0xa0> mr r1,r3 > 0000000000100204 <.__start+0xa4> li r3,0 > 0000000000100208 <.__start+0xa8> std r3,0(r1) > 000000000010020c <.__start+0xac> bl 00000000005c4af8 = <.mi_startup> > 0000000000100210 <.__start+0xb0> nop > 0000000000100214 <.__start+0xb4> b 0000000000100214 = <.__start+0xb4> >=20 >=20 >=20 > For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build): > (completes for buildkernel; fails for buildworld) >=20 > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker39a > /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 = syms=3D[0x8+0xd6860+0x8+0xf1193] > /boot/entropy size=3D0x1000 > Booting. . . > Kernel entry at 0x100160 >=20 > Invalid memory access at %SSR0: 00000000.00000000 = %SRR1:10000000.00081000 >=20 > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > >=20 > The only options at this point are: >=20 > mac-boot > shut-down >=20 > The problem here is a different code order and a matching > wrong start address that does not track the difference. > (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity > exists in the start routine as well. >=20 > Disassembly of section .text: > 0000000000100160 <.__start-0x2030> std r2,40(r1) > 0000000000100164 <.__start-0x202c> addis r2,r2,1 > 0000000000100168 <.__start-0x2028> addi r2,r2,-8 > 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 = <.cpu_switch> > 0000000000100170 <.__start-0x2020> std r2,40(r1) > 0000000000100174 <.__start-0x201c> addis r2,r2,1 > 0000000000100178 <.__start-0x2018> addi r2,r2,-8 > 000000000010017c <.__start-0x2014> b 0000000000ade6c8 = <.sf_buf_alloc> > 0000000000100180 <.__start-0x2010> std r2,40(r1) > 0000000000100184 <.__start-0x200c> addis r2,r2,1 > 0000000000100188 <.__start-0x2008> addi r2,r2,-8 > 000000000010018c <.__start-0x2004> b 0000000000a83f78 = <.vm_fault_hold> > 0000000000100190 <.__start-0x2000> std r2,40(r1) > 0000000000100194 <.__start-0x1ffc> addis r2,r2,1 > 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8 > 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 = <.fill_regs32> > 00000000001001a0 <.__start-0x1ff0> std r2,40(r1) > 00000000001001a4 <.__start-0x1fec> addis r2,r2,1 > 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8 > 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 = <.casueword32> > 00000000001001b0 <.__start-0x1fe0> std r2,40(r1) > 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1 > 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8 > 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 = <.kmap_free_wakeup> > . . . > 0000000000102190 <.__start> mfmsr r20 > 0000000000102194 <.__start+0x4> li r21,1 > 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010219c <.__start+0xc> mtmsrd r20 > 00000000001021a0 <.__start+0x10> isync > 00000000001021a4 <.__start+0x14> nop > 00000000001021a8 <.__start+0x18> b 00000000001021b0 = <.__start+0x20> > 00000000001021ac <.__start+0x1c> nop > 00000000001021b0 <.__start+0x20> nop > 00000000001021b4 <.__start+0x24> bl 00000000001021c0 = <.__start+0x30> > 00000000001021b8 <.__start+0x28> .long 0x0 > 00000000001021bc <.__start+0x2c> .long 0xfc8e48 > 00000000001021c0 <.__start+0x30> mflr r2 > 00000000001021c4 <.__start+0x34> ld r1,0(r2) > 00000000001021c8 <.__start+0x38> add r2,r1,r2 > 00000000001021cc <.__start+0x3c> ld r31,-32768(r2) > 00000000001021d0 <.__start+0x40> subf r31,r31,r2 > 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. = -32760 oddity!!! > 00000000001021d8 <.__start+0x48> addi r1,r1,16288 > 00000000001021dc <.__start+0x4c> add r1,r1,r31 > 00000000001021e0 <.__start+0x50> std r3,48(r1) > 00000000001021e4 <.__start+0x54> std r4,56(r1) > 00000000001021e8 <.__start+0x58> std r5,64(r1) > 00000000001021ec <.__start+0x5c> std r6,72(r1) > 00000000001021f0 <.__start+0x60> bl 00000000001021fc = <.__start+0x6c> > 00000000001021f4 <.__start+0x64> .long 0x0 > 00000000001021f8 <.__start+0x68> .long 0xfd4014 > 00000000001021fc <.__start+0x6c> mflr r3 > 0000000000102200 <.__start+0x70> ld r4,0(r3) > 0000000000102204 <.__start+0x74> add r3,r4,r3 > 0000000000102208 <.__start+0x78> mr r4,r31 > 000000000010220c <.__start+0x7c> bl 0000000000101a20 = > 0000000000102210 <.__start+0x80> ld r2,40(r1) > 0000000000102214 <.__start+0x84> ld r3,48(r1) > 0000000000102218 <.__start+0x88> ld r4,56(r1) > 000000000010221c <.__start+0x8c> ld r5,64(r1) > 0000000000102220 <.__start+0x90> ld r6,72(r1) > 0000000000102224 <.__start+0x94> mr r4,r2 > 0000000000102228 <.__start+0x98> bl 00000000001019a0 = > 000000000010222c <.__start+0x9c> ld r2,40(r1) > 0000000000102230 <.__start+0xa0> mr r1,r3 > 0000000000102234 <.__start+0xa4> li r3,0 > 0000000000102238 <.__start+0xa8> std r3,0(r1) > 000000000010223c <.__start+0xac> bl 00000000005c6b28 = <.mi_startup> > 0000000000102240 <.__start+0xb0> nop > 0000000000102244 <.__start+0xb4> b 0000000000102244 = <.__start+0xb4> >=20 >=20 > Who is most appropriate to send such information to for powerpc64? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Dec 8 23:26:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4FB7C6E74A for ; Thu, 8 Dec 2016 23:26:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (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 700311377 for ; Thu, 8 Dec 2016 23:26:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12798 invoked from network); 8 Dec 2016 23:27:35 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Dec 2016 23:27:35 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 08 Dec 2016 18:26:55 -0500 (EST) Received: (qmail 10503 invoked from network); 8 Dec 2016 23:26:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Dec 2016 23:26:55 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id F0921EC7B35; Thu, 8 Dec 2016 15:26:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net> Date: Thu, 8 Dec 2016 15:26:42 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net> To: Roman Divacky , Nathan Whitehorn X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 23:26:45 -0000 [Top post noting a systematic stupid typo of mine.] I keep typing 2.47 instead of 2.27 for devel/binutils and devel/powerpc64-binutils . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-8, at 3:01 PM, Mark Millard wrote: On 2016-Dec-8, at 2:14 PM, Roman Divacky wrote: > I believe the code comes from sys/powerpc/aim/locore64.S and if you = compare > the different values from the disssembly with the .S code you can see > it's __tocbase and TOC_REF(). >=20 > I wonder if the assembly has the -mminimal-toc knowledge hardcoded in = somehow. > I am not sure what expectations the locore64.S has about the kernel = layout that > we're probably breaking. >=20 > I've CCed Nathan Whitehorn. Nathan, can you take a look please? >=20 > Thanks, Roman For Nathan's reference about the context: I got to the point of having a clang 3.9.0 buildkernel finish for targeting powerpc64. But it does not boot. I'm working from head -r309656 with the following patches: (ignoring my usual PowerMac G5 powerpc64 booting hack related materials that I've had in place for a long time) # svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td = (revision 309656) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) @@ -2300,6 +2300,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle = counter // on a 32-bit target. let hasSideEffects =3D 1, usesCustomInserter =3D 1 in (Roman Divacky supplied the above patch.) # svnlite diff /usr/src/sys/modules/zfs/Makefile Index: /usr/src/sys/modules/zfs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/modules/zfs/Makefile (revision 309656) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,9 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS -.if ${MACHINE_ARCH} =3D=3D "powerpc64" -CFLAGS+=3D-mminimal-toc -.endif +#.if ${MACHINE_ARCH} =3D=3D "powerpc64" +#CFLAGS+=3D-mminimal-toc +#.endif .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 This last just avoids that clang 3.9.0 for targeting powerpc64 rejects the -mminimal-toc command line option. It being missing did not cause the buildkernel to stop. Note: I have booted with clang 3.9.0 based buildworld materials. (But C++ exception handling is still messed up so code dependent on C++ exceptions happening needs to be avoided.) I've had to avoid both WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants of devel/powerpc64-binutils or devel/binutils: I use older 2.25.1 devel/powerpc64-binutils or devel/binutils (on the powerpc64 itself). However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like binutils do not end up with ld failing and buildkernel appears to complete. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material: On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote: > [I have dropped the patch related information and just have > failing-boot related information here.] >=20 > On 2016-Dec-8, at 10:55 AM, Roman Divacky = wrote: >=20 >> Can you try to investigate why it dies? I am not convinced = -mminimal-toc >> would result in a boot failure. I think the kernel would fail to = link. >=20 > I give information for both devel/powerpc64-binutils based > and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different. >=20 > For using 2.25.1 of devel/powerpc64-binutils (a cross build): > (from camera image of screen) >=20 > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker390 > /boot/ker390/kernel data=3D0xf851a8+0x42dd98 = syms=3D[0x8+0xd6848+0x8+0xf1137] > /boot/entropy size=3D0x1000 > Booting. . . > Kernel entry at 0x100160 >=20 > Invalid memory access at %SSR0: 00000000.001001b0 = %SRR1:90000000.00003030 >=20 > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > >=20 > The only options at this point are: >=20 > mac-boot > shut-down >=20 >=20 > =46rom objdump for the above failing boot > but with notes added: > (Note: booting xtoolchain kernel starts at > 0000000000100120 instead; relative > offsets are unchanged and the code > is mostly the same.) >=20 > Disassembly of section .text: > 0000000000100160 <.__start> mfmsr r20 > 0000000000100164 <.__start+0x4> li r21,1 > 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010016c <.__start+0xc> mtmsrd r20 > 0000000000100170 <.__start+0x10> isync > 0000000000100174 <.__start+0x14> nop > 0000000000100178 <.__start+0x18> b 0000000000100180 = <.__start+0x20> > 000000000010017c <.__start+0x1c> nop > 0000000000100180 <.__start+0x20> nop > 0000000000100184 <.__start+0x24> bl 0000000000100190 = <.__start+0x30> > 0000000000100188 <.__start+0x28> .long 0x0 > 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20 > booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D = note > 0000000000100190 <.__start+0x30> mflr r2 > 0000000000100194 <.__start+0x34> ld r1,0(r2) > 0000000000100198 <.__start+0x38> add r2,r1,r2 > 000000000010019c <.__start+0x3c> ld r31,-32768(r2) > 00000000001001a0 <.__start+0x40> subf r31,r31,r2 > 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D= !!!!! > booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D = !!!!! > 00000000001001a8 <.__start+0x48> addi r1,r1,16288 > 00000000001001ac <.__start+0x4c> add r1,r1,r31 > 00000000001001b0 <.__start+0x50> std r3,48(r1) > SRR0 points at the above instruction > (I stopped comparing to the booting xtoolchain > based code after this.) > 00000000001001b4 <.__start+0x54> std r4,56(r1) > 00000000001001b8 <.__start+0x58> std r5,64(r1) > 00000000001001bc <.__start+0x5c> std r6,72(r1) > 00000000001001c0 <.__start+0x60> bl 00000000001001cc = <.__start+0x6c> > 00000000001001c4 <.__start+0x64> .long 0x0 > 00000000001001c8 <.__start+0x68> .long 0xf84ed4 > 00000000001001cc <.__start+0x6c> mflr r3 > 00000000001001d0 <.__start+0x70> ld r4,0(r3) > 00000000001001d4 <.__start+0x74> add r3,r4,r3 > 00000000001001d8 <.__start+0x78> mr r4,r31 > 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc = <.elf_reloc_self> > 00000000001001e0 <.__start+0x80> nop > 00000000001001e4 <.__start+0x84> ld r3,48(r1) > 00000000001001e8 <.__start+0x88> ld r4,56(r1) > 00000000001001ec <.__start+0x8c> ld r5,64(r1) > 00000000001001f0 <.__start+0x90> ld r6,72(r1) > 00000000001001f4 <.__start+0x94> mr r4,r2 > 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 = <.powerpc_init> > 00000000001001fc <.__start+0x9c> nop > 0000000000100200 <.__start+0xa0> mr r1,r3 > 0000000000100204 <.__start+0xa4> li r3,0 > 0000000000100208 <.__start+0xa8> std r3,0(r1) > 000000000010020c <.__start+0xac> bl 00000000005c4af8 = <.mi_startup> > 0000000000100210 <.__start+0xb0> nop > 0000000000100214 <.__start+0xb4> b 0000000000100214 = <.__start+0xb4> >=20 >=20 >=20 > For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build): > (completes for buildkernel; fails for buildworld) >=20 > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker39a > /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 = syms=3D[0x8+0xd6860+0x8+0xf1193] > /boot/entropy size=3D0x1000 > Booting. . . > Kernel entry at 0x100160 >=20 > Invalid memory access at %SSR0: 00000000.00000000 = %SRR1:10000000.00081000 >=20 > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > >=20 > The only options at this point are: >=20 > mac-boot > shut-down >=20 > The problem here is a different code order and a matching > wrong start address that does not track the difference. > (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity > exists in the start routine as well. >=20 > Disassembly of section .text: > 0000000000100160 <.__start-0x2030> std r2,40(r1) > 0000000000100164 <.__start-0x202c> addis r2,r2,1 > 0000000000100168 <.__start-0x2028> addi r2,r2,-8 > 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 = <.cpu_switch> > 0000000000100170 <.__start-0x2020> std r2,40(r1) > 0000000000100174 <.__start-0x201c> addis r2,r2,1 > 0000000000100178 <.__start-0x2018> addi r2,r2,-8 > 000000000010017c <.__start-0x2014> b 0000000000ade6c8 = <.sf_buf_alloc> > 0000000000100180 <.__start-0x2010> std r2,40(r1) > 0000000000100184 <.__start-0x200c> addis r2,r2,1 > 0000000000100188 <.__start-0x2008> addi r2,r2,-8 > 000000000010018c <.__start-0x2004> b 0000000000a83f78 = <.vm_fault_hold> > 0000000000100190 <.__start-0x2000> std r2,40(r1) > 0000000000100194 <.__start-0x1ffc> addis r2,r2,1 > 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8 > 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 = <.fill_regs32> > 00000000001001a0 <.__start-0x1ff0> std r2,40(r1) > 00000000001001a4 <.__start-0x1fec> addis r2,r2,1 > 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8 > 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 = <.casueword32> > 00000000001001b0 <.__start-0x1fe0> std r2,40(r1) > 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1 > 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8 > 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 = <.kmap_free_wakeup> > . . . > 0000000000102190 <.__start> mfmsr r20 > 0000000000102194 <.__start+0x4> li r21,1 > 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010219c <.__start+0xc> mtmsrd r20 > 00000000001021a0 <.__start+0x10> isync > 00000000001021a4 <.__start+0x14> nop > 00000000001021a8 <.__start+0x18> b 00000000001021b0 = <.__start+0x20> > 00000000001021ac <.__start+0x1c> nop > 00000000001021b0 <.__start+0x20> nop > 00000000001021b4 <.__start+0x24> bl 00000000001021c0 = <.__start+0x30> > 00000000001021b8 <.__start+0x28> .long 0x0 > 00000000001021bc <.__start+0x2c> .long 0xfc8e48 > 00000000001021c0 <.__start+0x30> mflr r2 > 00000000001021c4 <.__start+0x34> ld r1,0(r2) > 00000000001021c8 <.__start+0x38> add r2,r1,r2 > 00000000001021cc <.__start+0x3c> ld r31,-32768(r2) > 00000000001021d0 <.__start+0x40> subf r31,r31,r2 > 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. = -32760 oddity!!! > 00000000001021d8 <.__start+0x48> addi r1,r1,16288 > 00000000001021dc <.__start+0x4c> add r1,r1,r31 > 00000000001021e0 <.__start+0x50> std r3,48(r1) > 00000000001021e4 <.__start+0x54> std r4,56(r1) > 00000000001021e8 <.__start+0x58> std r5,64(r1) > 00000000001021ec <.__start+0x5c> std r6,72(r1) > 00000000001021f0 <.__start+0x60> bl 00000000001021fc = <.__start+0x6c> > 00000000001021f4 <.__start+0x64> .long 0x0 > 00000000001021f8 <.__start+0x68> .long 0xfd4014 > 00000000001021fc <.__start+0x6c> mflr r3 > 0000000000102200 <.__start+0x70> ld r4,0(r3) > 0000000000102204 <.__start+0x74> add r3,r4,r3 > 0000000000102208 <.__start+0x78> mr r4,r31 > 000000000010220c <.__start+0x7c> bl 0000000000101a20 = > 0000000000102210 <.__start+0x80> ld r2,40(r1) > 0000000000102214 <.__start+0x84> ld r3,48(r1) > 0000000000102218 <.__start+0x88> ld r4,56(r1) > 000000000010221c <.__start+0x8c> ld r5,64(r1) > 0000000000102220 <.__start+0x90> ld r6,72(r1) > 0000000000102224 <.__start+0x94> mr r4,r2 > 0000000000102228 <.__start+0x98> bl 00000000001019a0 = > 000000000010222c <.__start+0x9c> ld r2,40(r1) > 0000000000102230 <.__start+0xa0> mr r1,r3 > 0000000000102234 <.__start+0xa4> li r3,0 > 0000000000102238 <.__start+0xa8> std r3,0(r1) > 000000000010223c <.__start+0xac> bl 00000000005c6b28 = <.mi_startup> > 0000000000102240 <.__start+0xb0> nop > 0000000000102244 <.__start+0xb4> b 0000000000102244 = <.__start+0xb4> >=20 >=20 > Who is most appropriate to send such information to for powerpc64? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Fri Dec 9 02:13:53 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9007C6D2DE for ; Fri, 9 Dec 2016 02:13:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7D831A80 for ; Fri, 9 Dec 2016 02:13:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB92Dr36092363 for ; Fri, 9 Dec 2016 02:13:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 cross-built buildkernel stops for: rejected assembler notation Date: Fri, 09 Dec 2016 02:13:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 02:13:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904 --- Comment #2 from Mark Millard --- Created attachment 177812 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D177812&action= =3Dedit patch for contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Roman Divacky provided the patch and had me test it on am old PowerMac G5 so-called "Quad Core". It allowed hwpmc_e500.o to be built and the build to then continue on to other things instead of stopping. (The svnlite diff output is mine in order to be a comparison against a more modern version than roman originally used --and so mine has a closer file line number match.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Dec 9 02:20:59 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49A00C6D3B4 for ; Fri, 9 Dec 2016 02:20:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 389051C83 for ; Fri, 9 Dec 2016 02:20:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB92KxBj024252 for ; Fri, 9 Dec 2016 02:20:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c Date: Fri, 09 Dec 2016 02:20:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 02:20:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|head -r309179 clang 3.9.0 |head -r309179 clang 3.9.0 |TARGET_ARCH=3Dpowerpc64 |TARGET_ARCH=3Dpowerpc64 |cross-built buildkernel |buildkernel stops for: |stops for: rejected |rejected assembler notation |assembler notation |in hwpmc_e500.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Dec 9 02:47:37 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C71FC6DE6B for ; Fri, 9 Dec 2016 02:47:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (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 00ECEC3F for ; Fri, 9 Dec 2016 02:47:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14966 invoked from network); 9 Dec 2016 02:47:35 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Dec 2016 02:47:35 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 08 Dec 2016 21:47:46 -0500 (EST) Received: (qmail 2269 invoked from network); 9 Dec 2016 02:47:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Dec 2016 02:47:46 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 7531FEC9156; Thu, 8 Dec 2016 18:47:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . From: Mark Millard In-Reply-To: <20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net> Date: Thu, 8 Dec 2016 18:47:33 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <3EC1505A-962E-4679-AB5E-021ED352A284@dsl-only.net> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <29224379-EFB5-4FEE-ADDA-EB448773D248@dsl-only.net> <20480337-3CF7-4ED4-AB55-ADE18A3F0F75@dsl-only.net> To: Roman Divacky , Nathan Whitehorn X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 02:47:37 -0000 A context point that I forgot to mention. . . I had to use WERROR=3D in order for buildkernel to complete under clang 3.9.0 . Otherwise it stopped based on: converts between pointers to integer types with different sign = [-Werror,-Wpointer-sign] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-8, at 3:26 PM, Mark Millard wrote: [Top post noting a systematic stupid typo of mine.] I keep typing 2.47 instead of 2.27 for devel/binutils and devel/powerpc64-binutils . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-8, at 3:01 PM, Mark Millard wrote: On 2016-Dec-8, at 2:14 PM, Roman Divacky wrote: > I believe the code comes from sys/powerpc/aim/locore64.S and if you = compare > the different values from the disssembly with the .S code you can see > it's __tocbase and TOC_REF(). >=20 > I wonder if the assembly has the -mminimal-toc knowledge hardcoded in = somehow. > I am not sure what expectations the locore64.S has about the kernel = layout that > we're probably breaking. >=20 > I've CCed Nathan Whitehorn. Nathan, can you take a look please? >=20 > Thanks, Roman For Nathan's reference about the context: I got to the point of having a clang 3.9.0 buildkernel finish for targeting powerpc64. But it does not boot. I'm working from head -r309656 with the following patches: (ignoring my usual PowerMac G5 powerpc64 booting hack related materials that I've had in place for a long time) # svnlite diff /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td = (revision 309656) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) @@ -2300,6 +2300,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle = counter // on a 32-bit target. let hasSideEffects =3D 1, usesCustomInserter =3D 1 in (Roman Divacky supplied the above patch.) # svnlite diff /usr/src/sys/modules/zfs/Makefile Index: /usr/src/sys/modules/zfs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/modules/zfs/Makefile (revision 309656) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,9 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS -.if ${MACHINE_ARCH} =3D=3D "powerpc64" -CFLAGS+=3D-mminimal-toc -.endif +#.if ${MACHINE_ARCH} =3D=3D "powerpc64" +#CFLAGS+=3D-mminimal-toc +#.endif .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 This last just avoids that clang 3.9.0 for targeting powerpc64 rejects the -mminimal-toc command line option. It being missing did not cause the buildkernel to stop. Note: I have booted with clang 3.9.0 based buildworld materials. (But C++ exception handling is still messed up so code dependent on C++ exceptions happening needs to be avoided.) I've had to avoid both WITH_BINUTILS_BOOTSTRAP=3D like binutils and 2.47 variants of devel/powerpc64-binutils or devel/binutils: I use older 2.25.1 devel/powerpc64-binutils or devel/binutils (on the powerpc64 itself). However for buildkernel WITH_BINUTILS_BOOTSTRAP=3D like binutils do not end up with ld failing and buildkernel appears to complete. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material: On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote: > [I have dropped the patch related information and just have > failing-boot related information here.] >=20 > On 2016-Dec-8, at 10:55 AM, Roman Divacky = wrote: >=20 >> Can you try to investigate why it dies? I am not convinced = -mminimal-toc >> would result in a boot failure. I think the kernel would fail to = link. >=20 > I give information for both devel/powerpc64-binutils based > and for WITH_BINUTILS_BOOTSTRAP=3D based. They are different. >=20 > For using 2.25.1 of devel/powerpc64-binutils (a cross build): > (from camera image of screen) >=20 > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker390 > /boot/ker390/kernel data=3D0xf851a8+0x42dd98 = syms=3D[0x8+0xd6848+0x8+0xf1137] > /boot/entropy size=3D0x1000 > Booting. . . > Kernel entry at 0x100160 >=20 > Invalid memory access at %SSR0: 00000000.001001b0 = %SRR1:90000000.00003030 >=20 > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > >=20 > The only options at this point are: >=20 > mac-boot > shut-down >=20 >=20 > =46rom objdump for the above failing boot > but with notes added: > (Note: booting xtoolchain kernel starts at > 0000000000100120 instead; relative > offsets are unchanged and the code > is mostly the same.) >=20 > Disassembly of section .text: > 0000000000100160 <.__start> mfmsr r20 > 0000000000100164 <.__start+0x4> li r21,1 > 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010016c <.__start+0xc> mtmsrd r20 > 0000000000100170 <.__start+0x10> isync > 0000000000100174 <.__start+0x14> nop > 0000000000100178 <.__start+0x18> b 0000000000100180 = <.__start+0x20> > 000000000010017c <.__start+0x1c> nop > 0000000000100180 <.__start+0x20> nop > 0000000000100184 <.__start+0x24> bl 0000000000100190 = <.__start+0x30> > 0000000000100188 <.__start+0x28> .long 0x0 > 000000000010018c <.__start+0x2c> .long 0xf8ce78 =20 > booting xtoolchain based kernel has: 0xfebeb8 above <<<=3D=3D=3D = note > 0000000000100190 <.__start+0x30> mflr r2 > 0000000000100194 <.__start+0x34> ld r1,0(r2) > 0000000000100198 <.__start+0x38> add r2,r1,r2 > 000000000010019c <.__start+0x3c> ld r31,-32768(r2) > 00000000001001a0 <.__start+0x40> subf r31,r31,r2 > 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D= !!!!! > booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D = !!!!! > 00000000001001a8 <.__start+0x48> addi r1,r1,16288 > 00000000001001ac <.__start+0x4c> add r1,r1,r31 > 00000000001001b0 <.__start+0x50> std r3,48(r1) > SRR0 points at the above instruction > (I stopped comparing to the booting xtoolchain > based code after this.) > 00000000001001b4 <.__start+0x54> std r4,56(r1) > 00000000001001b8 <.__start+0x58> std r5,64(r1) > 00000000001001bc <.__start+0x5c> std r6,72(r1) > 00000000001001c0 <.__start+0x60> bl 00000000001001cc = <.__start+0x6c> > 00000000001001c4 <.__start+0x64> .long 0x0 > 00000000001001c8 <.__start+0x68> .long 0xf84ed4 > 00000000001001cc <.__start+0x6c> mflr r3 > 00000000001001d0 <.__start+0x70> ld r4,0(r3) > 00000000001001d4 <.__start+0x74> add r3,r4,r3 > 00000000001001d8 <.__start+0x78> mr r4,r31 > 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc = <.elf_reloc_self> > 00000000001001e0 <.__start+0x80> nop > 00000000001001e4 <.__start+0x84> ld r3,48(r1) > 00000000001001e8 <.__start+0x88> ld r4,56(r1) > 00000000001001ec <.__start+0x8c> ld r5,64(r1) > 00000000001001f0 <.__start+0x90> ld r6,72(r1) > 00000000001001f4 <.__start+0x94> mr r4,r2 > 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 = <.powerpc_init> > 00000000001001fc <.__start+0x9c> nop > 0000000000100200 <.__start+0xa0> mr r1,r3 > 0000000000100204 <.__start+0xa4> li r3,0 > 0000000000100208 <.__start+0xa8> std r3,0(r1) > 000000000010020c <.__start+0xac> bl 00000000005c4af8 = <.mi_startup> > 0000000000100210 <.__start+0xb0> nop > 0000000000100214 <.__start+0xb4> b 0000000000100214 = <.__start+0xb4> >=20 >=20 >=20 > For using WITH_BINUTILS_BOOTSTRAP=3D based binutils (a cross build): > (completes for buildkernel; fails for buildworld) >=20 > . . . (omitted material) . . . > Type '?' for a list of commands, 'help' for more detailed help. > OK unload > OK boot ker39a > /boot/ker39a/kernel data=3D0xfd6318+0x42dda8 = syms=3D[0x8+0xd6860+0x8+0xf1193] > /boot/entropy size=3D0x1000 > Booting. . . > Kernel entry at 0x100160 >=20 > Invalid memory access at %SSR0: 00000000.00000000 = %SRR1:10000000.00081000 >=20 > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > . . . (omitted material) . . . > ok > 0 > >=20 > The only options at this point are: >=20 > mac-boot > shut-down >=20 > The problem here is a different code order and a matching > wrong start address that does not track the difference. > (=46rom objdump.) Note: the same 0(r2) vs. -32760(r2) oddity > exists in the start routine as well. >=20 > Disassembly of section .text: > 0000000000100160 <.__start-0x2030> std r2,40(r1) > 0000000000100164 <.__start-0x202c> addis r2,r2,1 > 0000000000100168 <.__start-0x2028> addi r2,r2,-8 > 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 = <.cpu_switch> > 0000000000100170 <.__start-0x2020> std r2,40(r1) > 0000000000100174 <.__start-0x201c> addis r2,r2,1 > 0000000000100178 <.__start-0x2018> addi r2,r2,-8 > 000000000010017c <.__start-0x2014> b 0000000000ade6c8 = <.sf_buf_alloc> > 0000000000100180 <.__start-0x2010> std r2,40(r1) > 0000000000100184 <.__start-0x200c> addis r2,r2,1 > 0000000000100188 <.__start-0x2008> addi r2,r2,-8 > 000000000010018c <.__start-0x2004> b 0000000000a83f78 = <.vm_fault_hold> > 0000000000100190 <.__start-0x2000> std r2,40(r1) > 0000000000100194 <.__start-0x1ffc> addis r2,r2,1 > 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8 > 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 = <.fill_regs32> > 00000000001001a0 <.__start-0x1ff0> std r2,40(r1) > 00000000001001a4 <.__start-0x1fec> addis r2,r2,1 > 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8 > 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 = <.casueword32> > 00000000001001b0 <.__start-0x1fe0> std r2,40(r1) > 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1 > 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8 > 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 = <.kmap_free_wakeup> > . . . > 0000000000102190 <.__start> mfmsr r20 > 0000000000102194 <.__start+0x4> li r21,1 > 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0 > 000000000010219c <.__start+0xc> mtmsrd r20 > 00000000001021a0 <.__start+0x10> isync > 00000000001021a4 <.__start+0x14> nop > 00000000001021a8 <.__start+0x18> b 00000000001021b0 = <.__start+0x20> > 00000000001021ac <.__start+0x1c> nop > 00000000001021b0 <.__start+0x20> nop > 00000000001021b4 <.__start+0x24> bl 00000000001021c0 = <.__start+0x30> > 00000000001021b8 <.__start+0x28> .long 0x0 > 00000000001021bc <.__start+0x2c> .long 0xfc8e48 > 00000000001021c0 <.__start+0x30> mflr r2 > 00000000001021c4 <.__start+0x34> ld r1,0(r2) > 00000000001021c8 <.__start+0x38> add r2,r1,r2 > 00000000001021cc <.__start+0x3c> ld r31,-32768(r2) > 00000000001021d0 <.__start+0x40> subf r31,r31,r2 > 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. = -32760 oddity!!! > 00000000001021d8 <.__start+0x48> addi r1,r1,16288 > 00000000001021dc <.__start+0x4c> add r1,r1,r31 > 00000000001021e0 <.__start+0x50> std r3,48(r1) > 00000000001021e4 <.__start+0x54> std r4,56(r1) > 00000000001021e8 <.__start+0x58> std r5,64(r1) > 00000000001021ec <.__start+0x5c> std r6,72(r1) > 00000000001021f0 <.__start+0x60> bl 00000000001021fc = <.__start+0x6c> > 00000000001021f4 <.__start+0x64> .long 0x0 > 00000000001021f8 <.__start+0x68> .long 0xfd4014 > 00000000001021fc <.__start+0x6c> mflr r3 > 0000000000102200 <.__start+0x70> ld r4,0(r3) > 0000000000102204 <.__start+0x74> add r3,r4,r3 > 0000000000102208 <.__start+0x78> mr r4,r31 > 000000000010220c <.__start+0x7c> bl 0000000000101a20 = > 0000000000102210 <.__start+0x80> ld r2,40(r1) > 0000000000102214 <.__start+0x84> ld r3,48(r1) > 0000000000102218 <.__start+0x88> ld r4,56(r1) > 000000000010221c <.__start+0x8c> ld r5,64(r1) > 0000000000102220 <.__start+0x90> ld r6,72(r1) > 0000000000102224 <.__start+0x94> mr r4,r2 > 0000000000102228 <.__start+0x98> bl 00000000001019a0 = > 000000000010222c <.__start+0x9c> ld r2,40(r1) > 0000000000102230 <.__start+0xa0> mr r1,r3 > 0000000000102234 <.__start+0xa4> li r3,0 > 0000000000102238 <.__start+0xa8> std r3,0(r1) > 000000000010223c <.__start+0xac> bl 00000000005c6b28 = <.mi_startup> > 0000000000102240 <.__start+0xb0> nop > 0000000000102244 <.__start+0xb4> b 0000000000102244 = <.__start+0xb4> >=20 >=20 > Who is most appropriate to send such information to for powerpc64? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" _______________________________________________ freebsd-ppc@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:00:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A41AC6FFE1 for ; Sat, 10 Dec 2016 03:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED8C31963 for ; Sat, 10 Dec 2016 03:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA30vLA045139 for ; Sat, 10 Dec 2016 03:00:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215125] clang: Turning on sanitizer options causes the test for non-existent function mallinfo() to pass Date: Sat, 10 Dec 2016 03:00:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:00:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215125 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:09:36 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FC75C6F683 for ; Sat, 10 Dec 2016 03:09:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ECB47ED for ; Sat, 10 Dec 2016 03:09:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA39ah9042367 for ; Sat, 10 Dec 2016 03:09:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215107] head -r309656 clang 3.9.0 for TARGET_ARCH=powerpc: -mminimal-toc rejected (missing llvm 19098 fix?) Date: Sat, 10 Dec 2016 03:09:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:09:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215107 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:23:16 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5866C6F120 for ; Sat, 10 Dec 2016 03:23:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4499195B for ; Sat, 10 Dec 2016 03:23:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3NGxY069751 for ; Sat, 10 Dec 2016 03:23:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents Date: Sat, 10 Dec 2016 03:23:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:23:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:28:33 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86FDCC6F851 for ; Sat, 10 Dec 2016 03:28:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76A1A84 for ; Sat, 10 Dec 2016 03:28:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3SWTw014563 for ; Sat, 10 Dec 2016 03:28:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214973] bmake segfault on parenthesized variables. Date: Sat, 10 Dec 2016 03:28:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:28:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214973 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:29:14 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC494C6F99A for ; Sat, 10 Dec 2016 03:29:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B963B1BE for ; Sat, 10 Dec 2016 03:29:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3TEaw029083 for ; Sat, 10 Dec 2016 03:29:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031 Date: Sat, 10 Dec 2016 03:29:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:29:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214971 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 03:33:35 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FA74C6FEE8 for ; Sat, 10 Dec 2016 03:33:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2CAFB9F for ; Sat, 10 Dec 2016 03:33:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3XYOT053705 for ; Sat, 10 Dec 2016 03:33:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214904] head -r309179 clang 3.9.0 TARGET_ARCH=powerpc64 buildkernel stops for: rejected assembler notation in hwpmc_e500.c Date: Sat, 10 Dec 2016 03:33:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:33:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214904 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 08:50:30 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7252C6FB7F for ; Sat, 10 Dec 2016 08:50:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96CF81DB0 for ; Sat, 10 Dec 2016 08:50:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA8oUKr068770 for ; Sat, 10 Dec 2016 08:50:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215193] lib/libc++: convert to a private library Date: Sat, 10 Dec 2016 08:50:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter dependson Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 08:50:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193 Bug ID: 215193 Summary: lib/libc++: convert to a private library Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: feature Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org Depends on: 215192 libc++ version is currently tied to a specific FreeBSD release. If third-pa= rty software depends on bleeding edge C++ features it may fail to build. And pulling newer version from ports is risky due to ABI mismatch. To avoid Perl-style blunder let's promote the port version instead. For example, FreeBSD 10.x cannot benefit from complete C++14 support. Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215192 [Bug 215192] devel/libc++: phase out usage as part of USES=3Dcompiler:gcc-c++11-lib --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 08:52:56 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E93BC6FD3E for ; Sat, 10 Dec 2016 08:52:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1EB2F5 for ; Sat, 10 Dec 2016 08:52:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA8qtxS079491 for ; Sat, 10 Dec 2016 08:52:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215193] libc++ and libcxxrt: convert to a private library Date: Sat, 10 Dec 2016 08:52:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 08:52:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|lib/libc++: convert to a |libc++ and libcxxrt: |private library |convert to a private | |library --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 09:24:27 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BB5AC7067F for ; Sat, 10 Dec 2016 09:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B5CC1026 for ; Sat, 10 Dec 2016 09:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA9OR3O014088 for ; Sat, 10 Dec 2016 09:24:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215193] libc++ and libcxxrt: convert to a private library Date: Sat, 10 Dec 2016 09:24:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 09:24:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193 --- Comment #1 from Jan Beich (mail not working) --- Another issue is on libc++-enabled systems libstdc++ from ports cannot be u= sed. theraven@ proposed to link libstdc++ against libcxxrt (like in gcc42 case) = but that often requires bleeding edge version of it. 11.0+ release model should accelerate updates adoption but relying on libsupc++ compatibility still le= aves some gaps as FreeBSD tries to maintain ABI instead of leaving it to upstrea= m. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 11:09:12 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E47B7C70303 for ; Sat, 10 Dec 2016 11:09:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D41B51F7C for ; Sat, 10 Dec 2016 11:09:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBAB9Ctg012179 for ; Sat, 10 Dec 2016 11:09:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215193] libc++ and libcxxrt: convert to a private library Date: Sat, 10 Dec 2016 11:09:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 11:09:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215193 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |theraven@FreeBSD.org --- Comment #2 from David Chisnall --- I think that a better solution to this would be more frequent upstream impo= rts into base (which should become a lot easier to push to users once we have packaged base). Making libc++ a private library would mean that it would n= ot be possible for users to compile C++ programs without installing a port, wh= ich would be a major regression. If we did that, then there's little point hav= ing a C++ compiler in the base system at all. Libc++ aims to be backwards binary compatible, and so there shouldn't be any POLA violations from installing a newer one. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Dec 10 14:49:52 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A370DC6F2EB for ; Sat, 10 Dec 2016 14:49:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 923461083 for ; Sat, 10 Dec 2016 14:49:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBAEnq3U013657 for ; Sat, 10 Dec 2016 14:49:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215125] clang: Turning on sanitizer options causes the test for non-existent function mallinfo() to pass Date: Sat, 10 Dec 2016 14:49:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 14:49:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215125 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | Status|New |In Progress --- Comment #1 from Dimitry Andric --- Interesting, this is because the sanitizers have several interceptors for Linux-specific functions and variables, and these cause the link to succeed. I will check with upstream how we can best solve this. Most likely these interceptors should be disabled completely for FreeBSD. --=20 You are receiving this mail because: You are the assignee for the bug.=