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