From owner-freebsd-ppc@freebsd.org Sun Jan 8 00:28:57 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47E49C95E87 for ; Sun, 8 Jan 2017 00:28:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA028135F for ; Sun, 8 Jan 2017 00:28:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18525 invoked from network); 8 Jan 2017 00:29:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 Jan 2017 00:29:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 07 Jan 2017 19:29:01 -0500 (EST) Received: (qmail 13806 invoked from network); 8 Jan 2017 00:29:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jan 2017 00:29:01 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id BD7E2EC914D; Sat, 7 Jan 2017 16:28:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: Date: Sat, 7 Jan 2017 16:28:48 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> References: <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> To: Roman Divacky , Ed Maste , Mark Linimon X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 00:28:57 -0000 [Top post about FreeBSD bugzilla 215819 and llvm bugzilla 31574 submittals for the issue involved.] My guess is that FreeBSD will view this as a kernel source code issue and not as a toolchain issue. But it is only a guess on my part. I have submitted llvm bugzilla 31574 for this issue. It includes example .S file content that shows the "problem" in the generated .o file (form FreeBSD's view point). (I've no clue how llvm views its criteria relative to this mismatch with gcc/binutils.) Because FreeBSD source code changes (being explicit about @toc) avoid the distinction between clang and gcc/binutils I've not added 31574 to the Depends on list for llvm 25780 (the FreeBSD system compiler issues META entry in llvm). Someone with official status for FreeBSD could add 31574 to llvm's 25780 if FreeBSD wants to push llvm to match gcc/binutils for "@toc notation missing". Otherwise this is a kernel source code issue (as I would guess) and not a toolchain issue. Ed Maste or someone like that likely would make the final decision. I've added to FreeBSD Bugzilla 215819 the new information, including the simple example .S file content that shows the problem in the generated .o file. (Comments #3 and #4 have the new material.) My guess is that FreeBSD Bugzilla 215819 should no longer be assigned to freebsd-toolchain@FreeBSD.org . Instead it would be a powerpc64 kernel source code issue if I'm right. Ed Maste or someone like that likely would make this final decision as well. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-7, at 3:12 PM, Mark Millard wrote: > [I've supplied a list of places that adding @toc notation should > make clang 3.9.1 targeting powerpc64 do the right thing for > this issue.] >=20 > On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >=20 >> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>=20 >>> That's a great progress. Can you produce minimal self contained test = case that >>> exhibits this bug? And submit it to llvm bugzilla? >>>=20 >>> Also, clang3.9 defaults to using it's own internal asm, what happens = if you >>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>> this llvm assembly problem. Does it boot? >>>=20 >>> Thanks Mark, really great progress. >>>=20 >>> Roman >>=20 >> In attempting this I found how to control the behavior based on >> the assembler notation @toc being missing vs. being present. >>=20 >> If llvm should change is strongly tied to llvm's criteria for >> gcc compatibility relative to filling-in/defaulting omitted >> @toc's in the assembler notation. >>=20 >> FreeBSD has the option of always being explicit with @toc in order >> to avoid differences in handling of omitted notation. >>=20 >> So I've no clue if FreebSD wants to claim that a llvm change >> is a requirement for using clang as the powerpc64 system compiler. >>=20 >> [The issue of the distinction is submittable to llvm either way.] >>=20 >> Details. . . >>=20 >> For: >>=20 >> .section ".toc","aw" >> tmpstk.L: .tc tmpstk[TC],tmpstk >> . . . >> /* Set up the stack pointer */ >> ld %r1,tmpstk.L(%r2) >>=20 >> using devel/powerpc64-gcc gets: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >> = locore64_simplified.S >> locore64_simplified.S: Assembler messages: >> locore64_simplified.S:80: Warning: assuming @toc on symbol >>=20 >> and produces (with R_PPC64_TOC16_DS for .toc): >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>=20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_TOC16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >> By contrast clang is silent (cross compiler used): >>=20 >> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>=20 >> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_ADDR16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >>=20 >> But for: >>=20 >> .section ".toc","aw" >> tmpstk.L: .tc tmpstk[TC],tmpstk >> . . . >> /* Set up the stack pointer */ >> ld %r1,tmpstk.L@toc(%r2) >>=20 >> (note the @toc notation) both compilers agree and use >> R_PPC64_TOC16_DS for the .toc: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >> = locore64_simplified.S >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_TOC16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>=20 >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 >> locore64_simplified.o: file format elf64-powerpc-freebsd >>=20 >> RELOCATION RECORDS FOR [.text]: >> OFFSET TYPE VALUE=20 >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >> 0000000000000046 R_PPC64_TOC16_DS .toc >>=20 >>=20 >> RELOCATION RECORDS FOR [.toc]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 tmpstk >>=20 >>=20 >> RELOCATION RECORDS FOR [.opd]: >> OFFSET TYPE VALUE=20 >> 0000000000000000 R_PPC64_ADDR64 .__start >> 0000000000000008 R_PPC64_TOC *ABS* >>=20 >>=20 >>=20 >> I omitted "-f -gdwarf-2" to simplify things but with such >> clang complains about: >>=20 >> locore64_simplified.S:36:2: warning: DWARF2 only supports one section = per compilation unit >> .section ".toc","aw" >> ^ >> locore64_simplified.S:47:2: warning: DWARF2 only supports one section = per compilation unit >> .section ".opd","aw" >> ^ >>=20 >> (buildkernel gets such messages.) >>=20 >>=20 >> I expect I can simplify the .S code more than I have so far but >> I figured I'd report the discovery of the choice FreeBSD needs >> to make for powerpc64 for if llvm changes are to be required >> vs. not. >=20 > The following should be a list of the places that adding @toc usage > would fix some things for using clang 3.9.1 to target powerpc64: >=20 > # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more > /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol > /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on = symbol >=20 > devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report > on missing @toc 's. >=20 > But, of course, if some sections of code are conditionally compiled = and > excluded above they would not be listed. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 8 03:14:03 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAE43CA3CC1 for ; Sun, 8 Jan 2017 03:14:03 +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 DA8171766 for ; Sun, 8 Jan 2017 03:14:03 +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 v083E3Un018987 for ; Sun, 8 Jan 2017 03:14:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Sun, 08 Jan 2017 03:14:04 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 03:14:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #13 from Justin Hibbits --- Hi Curtis, I do all my ports builds using ports-mgmt/poudriere, which creates a pristi= ne jail for ports builds, so is a good test for if a patch is ready (can be a little difficult to set up at first, but I like it for my builds, since it doesn't affect the running system until I'm ready to install the ports, so I highly recommend it). This error, being generated in a poudriere jail, typically indicates that i= t's using gcc49 (from ports) as CC/CXX, but using /usr/bin/gcc for linking. I'm currently running a build via 'poudriere testport' to get a better log = and might be able to get a better indication of what's going on then. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 04:03:51 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E761CA583F for ; Sun, 8 Jan 2017 04:03:51 +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 061561866 for ; Sun, 8 Jan 2017 04:03:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8585 invoked from network); 8 Jan 2017 04:04:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Jan 2017 04:04:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 07 Jan 2017 23:04:03 -0500 (EST) Received: (qmail 29322 invoked from network); 8 Jan 2017 04:04:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jan 2017 04:04:03 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 40619EC900F; Sat, 7 Jan 2017 20:03:47 -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.2 \(3259\)) Subject: clang 3.9.1 based TARGET_ARCH=powerpc64 buildworld buildkernel for head -r311147 variant booted on PowerMac G5; used modern (2.27) devel/powerpc-binutils Message-Id: <99AE3534-E76D-41A5-98E8-7A7A6AB46492@dsl-only.net> Date: Sat, 7 Jan 2017 20:03:46 -0800 Cc: Roman Divacky , Ed Maste , Baptiste Daroussin , Justin Hibbits , nwhitehorn@FreeBSD.org To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 04:03:51 -0000 This was an amd64 -> powerpc64 cross build (kernel-toolchain buildkernel and separately buildworld). [Note: Anything dependent on throwing C++ exceptions in code generated by clang++ 3.9.1 is broken.] Various details: Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) . . . # uname -apKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan = 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 In the amd64 cross build context: # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 311147 Last Changed Rev: 311147 # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/aim/locore64.S M /usr/src/sys/powerpc/aim/trap_subr32.S M /usr/src/sys/powerpc/aim/trap_subr64.S M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/ofw/ofwcall64.S M /usr/src/sys/powerpc/powerpc/swtch64.S (Some of the above is not necessary. ofw_machdep.c is a PowerMac G5 specific workaround for unreliable booting that is from a openfirmware vs. FreeBSD interaction in the standard FreeBSD build. The ddb items are not required.) # more = ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host=20= 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 # WITH_CROSS_COMPILER=3D WITHOUT_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 # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 # # GENERIC -- Custom configuration for the powerpc/powerpc64 # include "GENERIC64" ident GENERIC64vtsc-NODGB makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 429946 Last Changed Rev: 429946 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 8 04:08:38 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76048CA59B4 for ; Sun, 8 Jan 2017 04:08:38 +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 65654191A for ; Sun, 8 Jan 2017 04:08:38 +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 v0848bgn024104 for ; Sun, 8 Jan 2017 04:08:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 211488] powerpc iso broken / does not burn correctly Date: Sun, 08 Jan 2017 04:08:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-BETA3 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: venture37@geeklan.co.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ppc@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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 04:08:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211488 --- Comment #9 from Sevan Janiyan --- Issue is definitely with Disk Utility.app on OS X Just managed to burn the FreeBSD-12.0-CURRENT-powerpc-20161221-r310361-disc1.iso using cdrecord with= out issue. cdrecord speed=3D8 dev=3D/dev/cd0c FreeBSD-12.0-CURRENT-powerpc-20161221-r310361-disc1.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.01 (powerpc-apple-netbsd7.99.56) Copyright (C) 1995-2015 Joerg Schilling scsidev: '/dev/cd0c' devname: '/dev/cd0c' scsibus: -2 target: -2 lun: -2 Using libscg version 'schily-0.9'. Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'MATSHITA' Identifikation : 'CD-RW CW-8123 ' Revision : 'CAD4' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-2 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. Starting to write CD/DVD/BD at speed 8 in real SAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Turning BURN-Free off cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Track 01: Total bytes read/written: 520865792/520865792 (254329 sectors).=20 Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r310361: Wed Dec 21 15:49:56 UTC 2016 root@releng3.nyi.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC powerpc gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. VT(ofwfb): resolution 1440x900 cpu0: IBM PowerPC 970FX revision 3.0, 900.40 MHz cpu0: Features dc000000 cpu0: HID0 511081 real memory =3D 2126036992 (2027 MB) avail memory =3D 2019106816 (1925 MB) random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: on nexus0 cpulist0: on ofwbus0 cpu0: on cpulist0 pcr0: on cpu0 powermac_nvram0: mem 0xfff04000-0xfff07fff on ofwbus0 powermac_nvram0: bank0 generation 222, bank1 generation 221 unin0: mem 0xf8000000-0xf8ffffff on ofwb= us0 unin0: Version 57 iichb0: mem 0xf8001000-0xf8001fff irq 0 on unin0 iicbus0: on iichb0 iicbus0: at addr 0x1c0 htpic0: mem 0xf8040000-0xf807ffff irq 224 on unin0 pcib0: mem 0xf0000000-0xf1ffffff on ofwbus0 pci0: on pcib0 vgapci0: mem 0x91000000-0x91ffffff,0xa0000000-0xa7ffffff irq 187 at device 16.0 on pci0 backlight0: on vgapci0 vgapci0: Boot video device agp0: on hostb0 pcib1: mem 0xf2000000-0xf47fffff,0xf8070000-0xf8070fff on ofwbus0 pcib1: 86 HT IRQs on device 1.0 pci1: on pcib1 pcib2: at device 1.0 on pci1 pci2: on pcib2 gem0: mem 0x80400000-0x805fffff irq 168 at dev= ice 15.0 on pci2 miibus0: on gem0 bmtphy0: PHY 0 on miibus0 bmtphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-= flow gem0: 10kB RX FIFO, 4kB TX FIFO gem0: Ethernet address: 00:0d:93: pcib3: at device 2.0 on pci1 pci3: on pcib3 macio0: mem 0x80000000-0x8007ffff at device 7.0 on = pci3 openpic0: mem 0x40000-0x7ffff on macio0 macgpio0: mem 0x50-0x8a on macio0 scc0: mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 151,145,146,152,147,148 on macio0 uart0: on scc0 uart1: on scc0 iichb1: mem 0x18000-0x18fff irq 155 on macio0 iicbus1: on iichb1 iicbus1: at addr 0x1c0 snapper0: at addr 0x6a on iicbus1 pcm0: mem 0x10000-0x10fff,0x8000-0x80ff,0x8100-0x81ff irq 156,139,140,157,141,142 on macio0 pci3: at device 1.0 (no driver attached) ohci0: mem 0x80082000-0x80082fff irq 198 at device 11.0 on pci3 usbus0 on ohci0 ohci1: mem 0x80081000-0x80081fff irq 198 at device 11.1 on pci3 usbus1 on ohci1 ehci0: mem 0x80080000-0x800800ff irq 19= 8 at device 11.2 on pci3 usbus2: EHCI version 1.0 usbus2 on ehci0 pcib4: at device 3.0 on pci1 pci4: on pcib4 atapci0: mem 0x80102000-0x80103fff irq = 138 at device 12.0 on pci4 pcib1: failed to reserve resource for pcib4 atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 ata4: at channel 2 on atapci0 ata5: at channel 3 on atapci0 ata0: mem 0x80104000-0x80107fff irq 166,165 at device 13.0 on pci4 fwohci0: <1394 Open Host Controller Interface> mem 0x80100000-0x80100fff irq 167 at device 14.0 on pci4 fwohci0: OHCI version 1.0 (ROM=3D0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:0d:93:ff:fe: fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0d:93: fwe0: Ethernet address: 02:0d:93: sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: PhysicalUpperBound register is not implemented. Physical memory access is limited to the first 4GB fwohci0: PhysicalUpperBound =3D 0x00000000 fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D2, CYCLEMAS= TER mode smu0: on ofwbus0 iichb2: on smu0 iicbus2: on iichb2 ds17750: at addr 0x92 on iicbus2 iicbus2: at addr 0xd4 iichb3: on smu0 iicbus3: on iichb3 cryptosoft0: on nexus0 NULL mp in getnewvnode() Timecounter "timebase" frequency 33333333 Hz quality 0 Event timer "decrementer" frequency 33333333 Hz quality 1000 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 uhub0: 2 ports with 2 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub2: 5 ports with 5 removable, self powered ugen2.2: at usbus2 uhub3 on uhub2 uhub3: on usb= us2 cd0 at ata0 bus 0 scbus4 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: Serial Number VFD200XXXXXXXX ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 305244MB (625140335 512 byte sectors)uhub3: 3 ports with 2 removable,= bus powered taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0 taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ada0s4 [rw]... --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 05:24:36 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1F52CA5F2F for ; Sun, 8 Jan 2017 05:24: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 C3457173F for ; Sun, 8 Jan 2017 05:24: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 v085Oa5D018234 for ; Sun, 8 Jan 2017 05:24:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Sun, 08 Jan 2017 05:24:36 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hamiltcl@verizon.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 05:24:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #14 from Curtis Hamilton --- I see. Using a jail is a good idea, as long as the jail environment is comparable to the live environment. However, different versions of runtime libraries can cause undesired behaviors. I have the luxury of having two separate systems for building and testing. >From what you've stated, I do believe what you are seeing is the difference= in the stdc++ libs used by GCC49 and /usr/bin/gcc. Especially, if 'usr/bin/gcc= ' is the stock GCC distribution. That is why I asked about '/etc/libmap.conf.' Y= ou can perform a quick check by checking for the presence, or absence, of 'GLIBCXX_3.4.18' by doing the following: strings /usr/lib/libstdc++*|grep GLIBCXX I've had this happen to me when building a port on one system and installin= g on another, after upgrading GCC on the build system.=20 BTW, what version of FreeBSD are you using? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 06:49:51 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF9FDCA51AF for ; Sun, 8 Jan 2017 06:49:51 +0000 (UTC) (envelope-from www-data@panel.top20remedies.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A52661B28 for ; Sun, 8 Jan 2017 06:49:51 +0000 (UTC) (envelope-from www-data@panel.top20remedies.com) Received: by freefall.freebsd.org (Postfix) id 0D8E563E7; Sun, 8 Jan 2017 06:49:51 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id EAC1563E6 for ; Sun, 8 Jan 2017 06:49:50 +0000 (UTC) (envelope-from www-data@panel.top20remedies.com) Received: from panel.top20remedies.com (unknown [IPv6:2a00:d880:5:679::84ba]) by mx1.freebsd.org (Postfix) with ESMTP id 005781B27 for ; Sun, 8 Jan 2017 06:49:46 +0000 (UTC) (envelope-from www-data@panel.top20remedies.com) Received: by panel.top20remedies.com (Postfix, from userid 33) id ADB587E84BFF; Sun, 8 Jan 2017 15:30:27 +0900 (TLT) To: freebsd-powerpc@freebsd.org Subject: Notification status of your delivery (FedEx 0000833635) X-PHP-Originating-Script: 33:post.php(5) : regexp code(1) : eval()'d code(17) : eval()'d code Date: Sun, 8 Jan 2017 15:30:27 +0900 MIME-Version: 1.0 Message-ID: <20f4aeabad4f3cfa0c4f720bf8d033e8@arabwalk.com> Reply-To: "FedEx Station Management" From: "FedEx Station Management" Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 06:49:52 -0000 Dear Customer, Your parcel was successfully delivered January 06 to FedEx Station, but our courier cound not contact you. You can find more details in this e-mail attachment! Yours respectfully, Seth Kemp, Chief Station Manager. From owner-freebsd-ppc@freebsd.org Sun Jan 8 09:05:45 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A370CA341C; Sun, 8 Jan 2017 09:05:45 +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 884091B0A; Sun, 8 Jan 2017 09:05:43 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 0DA9C12CB9F; Sun, 8 Jan 2017 10:03:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1483866188; bh=Mc+y5K9OwtN8E37o63Efpr1YivqA+oNZVY/CnxZaUZA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=qLXTAeZVnaCYIKRJxebKjFTSpSl5HUj4kop1+/qACF9vU/3LCXynJla5p+sW+iIhe eo/EjjZVUIV1bVYNawRS5VM5hu+ejTj2qdo3ALeQ98xX7IHi2JnItnSQfB6J9J2Yfd DmBs0luxwSQetikGVMMRqD7vsncfURhyOSgDWL6s= Date: Sun, 8 Jan 2017 10:03:08 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , Mark Linimon , 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. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] Message-ID: <20170108090307.GA3140@vlakno.cz> References: <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@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: <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 09:05:45 -0000 I think we should add the @toc notations to all the places where it's neede= d. Can you submit such a patch (perhaps with the one for adding 0 to the cmp instruction) so they can be committed to FreeBSD repo? If gnu as warns and llvm assembler does the wrong thing without @toc and bo= th do the correct thing with @toc I think it's an obvious decision. Also, with all these changes. Does clang compiled kernel boot? On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: > [Top post about FreeBSD bugzilla 215819 and llvm bugzilla > 31574 submittals for the issue involved.] >=20 > My guess is that FreeBSD will view this as a kernel > source code issue and not as a toolchain issue. But > it is only a guess on my part. >=20 >=20 > I have submitted llvm bugzilla 31574 for this issue. It > includes example .S file content that shows the "problem" > in the generated .o file (form FreeBSD's view point). > (I've no clue how llvm views its criteria relative to this > mismatch with gcc/binutils.) >=20 > Because FreeBSD source code changes (being explicit about > @toc) avoid the distinction between clang and gcc/binutils > I've not added 31574 to the Depends on list for llvm 25780 > (the FreeBSD system compiler issues META entry in llvm). >=20 > Someone with official status for FreeBSD could add 31574 to > llvm's 25780 if FreeBSD wants to push llvm to match > gcc/binutils for "@toc notation missing". >=20 > Otherwise this is a kernel source code issue (as I would > guess) and not a toolchain issue. >=20 > Ed Maste or someone like that likely would make the final > decision. >=20 >=20 > I've added to FreeBSD Bugzilla 215819 the new information, > including the simple example .S file content that shows the > problem in the generated .o file. (Comments #3 and #4 > have the new material.) >=20 > My guess is that FreeBSD Bugzilla 215819 should no longer > be assigned to freebsd-toolchain@FreeBSD.org . Instead it > would be a powerpc64 kernel source code issue if I'm right. >=20 > Ed Maste or someone like that likely would make this final > decision as well. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-7, at 3:12 PM, Mark Millard wrote: >=20 > > [I've supplied a list of places that adding @toc notation should > > make clang 3.9.1 targeting powerpc64 do the right thing for > > this issue.] > >=20 > > On 2017-Jan-7, at 2:07 PM, Mark Millard wrote: > >=20 > >> On 2017-Jan-7, at 12:51 AM, Roman Divacky wrot= e: > >>=20 > >>> That's a great progress. Can you produce minimal self contained test = case that > >>> exhibits this bug? And submit it to llvm bugzilla? > >>>=20 > >>> Also, clang3.9 defaults to using it's own internal asm, what happens = if you > >>> add -no-integrated-as to CFLAGS and recompile the kernel? That should= remove > >>> this llvm assembly problem. Does it boot? > >>>=20 > >>> Thanks Mark, really great progress. > >>>=20 > >>> Roman > >>=20 > >> In attempting this I found how to control the behavior based on > >> the assembler notation @toc being missing vs. being present. > >>=20 > >> If llvm should change is strongly tied to llvm's criteria for > >> gcc compatibility relative to filling-in/defaulting omitted > >> @toc's in the assembler notation. > >>=20 > >> FreeBSD has the option of always being explicit with @toc in order > >> to avoid differences in handling of omitted notation. > >>=20 > >> So I've no clue if FreebSD wants to claim that a llvm change > >> is a requirement for using clang as the powerpc64 system compiler. > >>=20 > >> [The issue of the distinction is submittable to llvm either way.] > >>=20 > >> Details. . . > >>=20 > >> For: > >>=20 > >> .section ".toc","aw" > >> tmpstk.L: .tc tmpstk[TC],tmpstk > >> . . . > >> /* Set up the stack pointer */ > >> ld %r1,tmpstk.L(%r2) > >>=20 > >> using devel/powerpc64-gcc gets: > >>=20 > >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = -= pipe \ = = =20 > =20 > >=20 > >> = locore64_simplified.S > >> locore64_simplified.S: Assembler messages: > >> locore64_simplified.S:80: Warning: assuming @toc on symbol > >>=20 > >> and produces (with R_PPC64_TOC16_DS for .toc): > >>=20 > >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o > >>=20 > >> locore64_simplified.o: file format elf64-powerpc-freebsd > >>=20 > >> RELOCATION RECORDS FOR [.text]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >> 0000000000000046 R_PPC64_TOC16_DS .toc > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.toc]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.opd]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 .__start > >> 0000000000000008 R_PPC64_TOC *ABS* > >>=20 > >>=20 > >> By contrast clang is silent (cross compiler used): > >>=20 > >> # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/us= r/bin/cc \ = = -target powerpc64-unkn= own-freebsd12.0 \ = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/p= owerpc.powerpc64/usr/src/tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 > =20 > >=20 > >> = -c \ = = = -x a= ssembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S > >>=20 > >> and produces code with R_PPC64_ADDR16_DS for the .toc instead: > >>=20 > >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 > >> locore64_simplified.o: file format elf64-powerpc-freebsd > >>=20 > >> RELOCATION RECORDS FOR [.text]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >> 0000000000000046 R_PPC64_ADDR16_DS .toc > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.toc]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.opd]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 .__start > >> 0000000000000008 R_PPC64_TOC *ABS* > >>=20 > >>=20 > >>=20 > >> But for: > >>=20 > >> .section ".toc","aw" > >> tmpstk.L: .tc tmpstk[TC],tmpstk > >> . . . > >> /* Set up the stack pointer */ > >> ld %r1,tmpstk.L@toc(%r2) > >>=20 > >> (note the @toc notation) both compilers agree and use > >> R_PPC64_TOC16_DS for the .toc: > >>=20 > >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = -= pipe \ = = =20 > =20 > >=20 > >> = locore64_simplified.S > >>=20 > >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 > >> locore64_simplified.o: file format elf64-powerpc-freebsd > >>=20 > >> RELOCATION RECORDS FOR [.text]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >> 0000000000000046 R_PPC64_TOC16_DS .toc > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.toc]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.opd]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 .__start > >> 0000000000000008 R_PPC64_TOC *ABS* > >>=20 > >>=20 > >> # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/us= r/bin/cc \ = = -target powerpc64-unkn= own-freebsd12.0 \ = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/p= owerpc.powerpc64/usr/src/tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 > =20 > >=20 > >> = -c \ = = = -x a= ssembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S > >>=20 > >> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | = more = = =20 > >> locore64_simplified.o: file format elf64-powerpc-freebsd > >>=20 > >> RELOCATION RECORDS FOR [.text]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >> 0000000000000046 R_PPC64_TOC16_DS .toc > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.toc]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>=20 > >>=20 > >> RELOCATION RECORDS FOR [.opd]: > >> OFFSET TYPE VALUE=20 > >> 0000000000000000 R_PPC64_ADDR64 .__start > >> 0000000000000008 R_PPC64_TOC *ABS* > >>=20 > >>=20 > >>=20 > >> I omitted "-f -gdwarf-2" to simplify things but with such > >> clang complains about: > >>=20 > >> locore64_simplified.S:36:2: warning: DWARF2 only supports one section = per compilation unit > >> .section ".toc","aw" > >> ^ > >> locore64_simplified.S:47:2: warning: DWARF2 only supports one section = per compilation unit > >> .section ".opd","aw" > >> ^ > >>=20 > >> (buildkernel gets such messages.) > >>=20 > >>=20 > >> I expect I can simplify the .S code more than I have so far but > >> I figured I'd report the discovery of the choice FreeBSD needs > >> to make for powerpc64 for if llvm changes are to be required > >> vs. not. > >=20 > > The following should be a list of the places that adding @toc usage > > would fix some things for using clang 3.9.1 to target powerpc64: > >=20 > > # grep "@toc[^b]" /root/sys_typescripts/typescript_make_powerpc64vtsc_n= odebug_incl_clang_xtoolchain_kernel-amd64-host-2017-01-03:23:48:41 | more > > /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on symb= ol > > /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on s= ymbol > > /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on s= ymbol > > /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on sym= bol > > /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on sym= bol > > /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on sym= bol > > /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on sym= bol > > /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on sym= bol > > /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on sym= bol > > /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on s= ymbol > >=20 > > devel/powerpc64-gcc and devel/powerpc64-binutils together happens to re= port > > on missing @toc 's. > >=20 > > But, of course, if some sections of code are conditionally compiled and > > excluded above they would not be listed. > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.o= rg" From owner-freebsd-ppc@freebsd.org Sun Jan 8 10:24:21 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18748CA2B4A for ; Sun, 8 Jan 2017 10:24:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-13.reflexion.net [208.70.210.13]) (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 CA710111B for ; Sun, 8 Jan 2017 10:24:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29430 invoked from network); 8 Jan 2017 10:24:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Jan 2017 10:24:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sun, 08 Jan 2017 05:24:33 -0500 (EST) Received: (qmail 25069 invoked from network); 8 Jan 2017 10:24:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jan 2017 10:24:33 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id BB428EC7B24; Sun, 8 Jan 2017 02:24:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <20170108090307.GA3140@vlakno.cz> Date: Sun, 8 Jan 2017 02:24:17 -0800 Cc: Ed Maste , Mark Linimon , FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> References: <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 10:24:21 -0000 On 2017-Jan-8, at 1:03 AM, Roman Divacky wrote: > I think we should add the @toc notations to all the places where it's = needed. > Can you submit such a patch (perhaps with the one for adding 0 to the = cmp > instruction) so they can be committed to FreeBSD repo? In order to test I added @toc to each of the 10 instructions instead of adjusting the macros so that instructions would automatically get the notation but other (what are now) TOC_REF(...) usage would not that should not. I suspect Nathan and Justin might prefer a more automatic alternative so that TOC_REF(...) in an instruction would be sufficient without an explicit @toc in the instruction. I'll see about switching to such code before providing a patch. I'd include the "0, " update to the cmp instruction. But adding @toc's in those instructions (with prior workarounds as well) did allow me to build a bootable system based on using devel/powerpc64-binutils and clang 3.9.1 for both buildworld and buildkernel --still using clang's internal assembler. One issue is that clang does not support (or need) the -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 requires it. For sys/modules/zfs/Makefile my source currently does not support gcc 4.2.1 without editing. As I remember devel/powerpc64-gcc (devel/powerpc64-xtoolchain-gcc) does not require the -mminimal-toc either. But devel/powerpc64-gcc does allow -mminimal-toc so it can be a clang vs. gcc based choice. I might also deal with that before providing patches. Note: -mlongcall was also not needed nor used for clang. (Still used for gcc.) sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 and -Wa,-mppc64bridge that I eliminated (they messed up 32-bit powerpc builds) but I've no way to test kboot that I know of. This patch might be rejected. Remember that I got this far in part by using your partial e500-instructions patch. I can provide my variant that is a diff with -r311147 instead of an older place in the history. But it would be incomplete coverage of those 2 instructions in clang. Also I build with a workaround for PowerMac G5 boot reliability since OpenFirmware and FreeBSD interact badly at times on PowerMac G5's. This I would not provide as it is PowerMac G5 specific. > If gnu as warns and llvm assembler does the wrong thing without @toc = and both > do the correct thing with @toc I think it's an obvious decision. My choice would be to supply the @toc notation in some way, not necessarily the form I used for the initial test. > Also, with all these changes. Does clang compiled kernel boot? The PowerMac G5 so-called "Quad Core" that I currently have access to is now running from buildworld and buildkernel based on devel/powerpc64-binutils and clang 3.9.1 : Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) . . . # uname -apKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan = 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 I've built about a dozen ports on it after booting but I've not done a self-hosted buildworld buildkernel yet. [Note: Anything dependent on throwing C++ exceptions in code generated by clang++ 3.9.1 is broken.] =3D=3D=3D Mark Millard markmi at dsl-only.net On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: > [Top post about FreeBSD bugzilla 215819 and llvm bugzilla > 31574 submittals for the issue involved.] >=20 > My guess is that FreeBSD will view this as a kernel > source code issue and not as a toolchain issue. But > it is only a guess on my part. >=20 >=20 > I have submitted llvm bugzilla 31574 for this issue. It > includes example .S file content that shows the "problem" > in the generated .o file (form FreeBSD's view point). > (I've no clue how llvm views its criteria relative to this > mismatch with gcc/binutils.) >=20 > Because FreeBSD source code changes (being explicit about > @toc) avoid the distinction between clang and gcc/binutils > I've not added 31574 to the Depends on list for llvm 25780 > (the FreeBSD system compiler issues META entry in llvm). >=20 > Someone with official status for FreeBSD could add 31574 to > llvm's 25780 if FreeBSD wants to push llvm to match > gcc/binutils for "@toc notation missing". >=20 > Otherwise this is a kernel source code issue (as I would > guess) and not a toolchain issue. >=20 > Ed Maste or someone like that likely would make the final > decision. >=20 >=20 > I've added to FreeBSD Bugzilla 215819 the new information, > including the simple example .S file content that shows the > problem in the generated .o file. (Comments #3 and #4 > have the new material.) >=20 > My guess is that FreeBSD Bugzilla 215819 should no longer > be assigned to freebsd-toolchain@FreeBSD.org . Instead it > would be a powerpc64 kernel source code issue if I'm right. >=20 > Ed Maste or someone like that likely would make this final > decision as well. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-7, at 3:12 PM, Mark Millard = wrote: >=20 >> [I've supplied a list of places that adding @toc notation should >> make clang 3.9.1 targeting powerpc64 do the right thing for >> this issue.] >>=20 >> On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >>=20 >>> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>>=20 >>>> That's a great progress. Can you produce minimal self contained = test case that >>>> exhibits this bug? And submit it to llvm bugzilla? >>>>=20 >>>> Also, clang3.9 defaults to using it's own internal asm, what = happens if you >>>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>>> this llvm assembly problem. Does it boot? >>>>=20 >>>> Thanks Mark, really great progress. >>>>=20 >>>> Roman >>>=20 >>> In attempting this I found how to control the behavior based on >>> the assembler notation @toc being missing vs. being present. >>>=20 >>> If llvm should change is strongly tied to llvm's criteria for >>> gcc compatibility relative to filling-in/defaulting omitted >>> @toc's in the assembler notation. >>>=20 >>> FreeBSD has the option of always being explicit with @toc in order >>> to avoid differences in handling of omitted notation. >>>=20 >>> So I've no clue if FreebSD wants to claim that a llvm change >>> is a requirement for using clang as the powerpc64 system compiler. >>>=20 >>> [The issue of the distinction is submittable to llvm either way.] >>>=20 >>> Details. . . >>>=20 >>> For: >>>=20 >>> .section ".toc","aw" >>> tmpstk.L: .tc tmpstk[TC],tmpstk >>> . . . >>> /* Set up the stack pointer */ >>> ld %r1,tmpstk.L(%r2) >>>=20 >>> using devel/powerpc64-gcc gets: >>>=20 >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>> = locore64_simplified.S >>> locore64_simplified.S: Assembler messages: >>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>=20 >>> and produces (with R_PPC64_TOC16_DS for .toc): >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>>=20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>> By contrast clang is silent (cross compiler used): >>>=20 >>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>=20 >>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>>=20 >>> But for: >>>=20 >>> .section ".toc","aw" >>> tmpstk.L: .tc tmpstk[TC],tmpstk >>> . . . >>> /* Set up the stack pointer */ >>> ld %r1,tmpstk.L@toc(%r2) >>>=20 >>> (note the @toc notation) both compilers agree and use >>> R_PPC64_TOC16_DS for the .toc: >>>=20 >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>> = locore64_simplified.S >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>>=20 >>> I omitted "-f -gdwarf-2" to simplify things but with such >>> clang complains about: >>>=20 >>> locore64_simplified.S:36:2: warning: DWARF2 only supports one = section per compilation unit >>> .section ".toc","aw" >>> ^ >>> locore64_simplified.S:47:2: warning: DWARF2 only supports one = section per compilation unit >>> .section ".opd","aw" >>> ^ >>>=20 >>> (buildkernel gets such messages.) >>>=20 >>>=20 >>> I expect I can simplify the .S code more than I have so far but >>> I figured I'd report the discovery of the choice FreeBSD needs >>> to make for powerpc64 for if llvm changes are to be required >>> vs. not. >>=20 >> The following should be a list of the places that adding @toc usage >> would fix some things for using clang 3.9.1 to target powerpc64: >>=20 >> # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more >> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on = symbol >>=20 >> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report >> on missing @toc 's. >>=20 >> But, of course, if some sections of code are conditionally compiled = and >> excluded above they would not be listed. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > _______________________________________________ > 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-ppc@freebsd.org Sun Jan 8 10:57:14 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9876CA5198 for ; Sun, 8 Jan 2017 10:57:14 +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 870711B9B for ; Sun, 8 Jan 2017 10:57:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24471 invoked from network); 8 Jan 2017 10:57:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Jan 2017 10:57:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sun, 08 Jan 2017 05:57:12 -0500 (EST) Received: (qmail 30566 invoked from network); 8 Jan 2017 10:57:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jan 2017 10:57:12 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id BC5FBEC861A; Sun, 8 Jan 2017 02:57:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> Date: Sun, 8 Jan 2017 02:57:11 -0800 Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML , Ed Maste , Mark Linimon Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 10:57:14 -0000 [I forgot to indicate that I still can not use the system bootstrapped ld command and so there is a reason that I used = devel/powerpc64-binutils.] On 2017-Jan-8, at 2:24 AM, Mark Millard wrote: > On 2017-Jan-8, at 1:03 AM, Roman Divacky = wrote: >=20 >> I think we should add the @toc notations to all the places where it's = needed. >> Can you submit such a patch (perhaps with the one for adding 0 to the = cmp >> instruction) so they can be committed to FreeBSD repo? >=20 > In order to test I added @toc to each of the 10 instructions instead > of adjusting the macros so that instructions would automatically > get the notation but other (what are now) TOC_REF(...) usage would > not that should not. >=20 > I suspect Nathan and Justin might prefer a more automatic > alternative so that TOC_REF(...) in an instruction would > be sufficient without an explicit @toc in the instruction. >=20 > I'll see about switching to such code before providing a > patch. I'd include the "0, " update to the cmp instruction. >=20 > But adding @toc's in those instructions (with prior workarounds > as well) did allow me to build a bootable system based on using > devel/powerpc64-binutils and clang 3.9.1 for both buildworld > and buildkernel --still using clang's internal assembler. >=20 > One issue is that clang does not support (or need) the > -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 > requires it. For sys/modules/zfs/Makefile my source > currently does not support gcc 4.2.1 without editing. > As I remember devel/powerpc64-gcc > (devel/powerpc64-xtoolchain-gcc) does not require the > -mminimal-toc either. But devel/powerpc64-gcc does > allow -mminimal-toc so it can be a clang vs. gcc based > choice. >=20 > I might also deal with that before providing patches. >=20 > Note: -mlongcall was also not needed nor used for clang. > (Still used for gcc.) >=20 > sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 > and -Wa,-mppc64bridge that I eliminated (they messed up > 32-bit powerpc builds) but I've no way to test kboot that > I know of. This patch might be rejected. >=20 > Remember that I got this far in part by using your partial > e500-instructions patch. I can provide my variant that > is a diff with -r311147 instead of an older place in the > history. But it would be incomplete coverage of those 2 > instructions in clang. >=20 > Also I build with a workaround for PowerMac G5 boot > reliability since OpenFirmware and FreeBSD interact > badly at times on PowerMac G5's. This I would not > provide as it is PowerMac G5 specific. >=20 >> If gnu as warns and llvm assembler does the wrong thing without @toc = and both >> do the correct thing with @toc I think it's an obvious decision. >=20 > My choice would be to supply the @toc notation in some way, > not necessarily the form I used for the initial test. >=20 >> Also, with all these changes. Does clang compiled kernel boot? >=20 > The PowerMac G5 so-called "Quad Core" that I currently have access > to is now running from buildworld and buildkernel based on > devel/powerpc64-binutils and clang 3.9.1 : >=20 > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 > = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc > FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) > . . . >=20 > # uname -apKU > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan = 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 >=20 > I've built about a dozen ports on it after booting but I've not > done a self-hosted buildworld buildkernel yet. >=20 > [Note: Anything dependent on throwing C++ exceptions in > code generated by clang++ 3.9.1 is broken.] I should have been explicit: I still can not use the system bootstrapped ld command and such binutils for buildkernel and so there is a reason that I used devel/powerpc64-binutils instead. Thus even with my patches clang 3.9.1 would not be ready for general use or for a default way of building. I have to have a tailored SRC_ENV_CONF file or the like still --and a port built and installed. [On a powerpc64 system devel/binutils could be used.] There is also the issue with throwing C++ exceptions in code when clang 3.9.1 was the code generator used. =3D=3D=3D Mark Millard markmi at dsl-only.net On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: > [Top post about FreeBSD bugzilla 215819 and llvm bugzilla > 31574 submittals for the issue involved.] >=20 > My guess is that FreeBSD will view this as a kernel > source code issue and not as a toolchain issue. But > it is only a guess on my part. >=20 >=20 > I have submitted llvm bugzilla 31574 for this issue. It > includes example .S file content that shows the "problem" > in the generated .o file (form FreeBSD's view point). > (I've no clue how llvm views its criteria relative to this > mismatch with gcc/binutils.) >=20 > Because FreeBSD source code changes (being explicit about > @toc) avoid the distinction between clang and gcc/binutils > I've not added 31574 to the Depends on list for llvm 25780 > (the FreeBSD system compiler issues META entry in llvm). >=20 > Someone with official status for FreeBSD could add 31574 to > llvm's 25780 if FreeBSD wants to push llvm to match > gcc/binutils for "@toc notation missing". >=20 > Otherwise this is a kernel source code issue (as I would > guess) and not a toolchain issue. >=20 > Ed Maste or someone like that likely would make the final > decision. >=20 >=20 > I've added to FreeBSD Bugzilla 215819 the new information, > including the simple example .S file content that shows the > problem in the generated .o file. (Comments #3 and #4 > have the new material.) >=20 > My guess is that FreeBSD Bugzilla 215819 should no longer > be assigned to freebsd-toolchain@FreeBSD.org . Instead it > would be a powerpc64 kernel source code issue if I'm right. >=20 > Ed Maste or someone like that likely would make this final > decision as well. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-7, at 3:12 PM, Mark Millard = wrote: >=20 >> [I've supplied a list of places that adding @toc notation should >> make clang 3.9.1 targeting powerpc64 do the right thing for >> this issue.] >>=20 >> On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >>=20 >>> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>>=20 >>>> That's a great progress. Can you produce minimal self contained = test case that >>>> exhibits this bug? And submit it to llvm bugzilla? >>>>=20 >>>> Also, clang3.9 defaults to using it's own internal asm, what = happens if you >>>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>>> this llvm assembly problem. Does it boot? >>>>=20 >>>> Thanks Mark, really great progress. >>>>=20 >>>> Roman >>>=20 >>> In attempting this I found how to control the behavior based on >>> the assembler notation @toc being missing vs. being present. >>>=20 >>> If llvm should change is strongly tied to llvm's criteria for >>> gcc compatibility relative to filling-in/defaulting omitted >>> @toc's in the assembler notation. >>>=20 >>> FreeBSD has the option of always being explicit with @toc in order >>> to avoid differences in handling of omitted notation. >>>=20 >>> So I've no clue if FreebSD wants to claim that a llvm change >>> is a requirement for using clang as the powerpc64 system compiler. >>>=20 >>> [The issue of the distinction is submittable to llvm either way.] >>>=20 >>> Details. . . >>>=20 >>> For: >>>=20 >>> .section ".toc","aw" >>> tmpstk.L: .tc tmpstk[TC],tmpstk >>> . . . >>> /* Set up the stack pointer */ >>> ld %r1,tmpstk.L(%r2) >>>=20 >>> using devel/powerpc64-gcc gets: >>>=20 >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>> = locore64_simplified.S >>> locore64_simplified.S: Assembler messages: >>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>=20 >>> and produces (with R_PPC64_TOC16_DS for .toc): >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>>=20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>> By contrast clang is silent (cross compiler used): >>>=20 >>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>=20 >>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>>=20 >>> But for: >>>=20 >>> .section ".toc","aw" >>> tmpstk.L: .tc tmpstk[TC],tmpstk >>> . . . >>> /* Set up the stack pointer */ >>> ld %r1,tmpstk.L@toc(%r2) >>>=20 >>> (note the @toc notation) both compilers agree and use >>> R_PPC64_TOC16_DS for the .toc: >>>=20 >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>> = locore64_simplified.S >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>=20 >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.toc]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.opd]: >>> OFFSET TYPE VALUE=20 >>> 0000000000000000 R_PPC64_ADDR64 .__start >>> 0000000000000008 R_PPC64_TOC *ABS* >>>=20 >>>=20 >>>=20 >>> I omitted "-f -gdwarf-2" to simplify things but with such >>> clang complains about: >>>=20 >>> locore64_simplified.S:36:2: warning: DWARF2 only supports one = section per compilation unit >>> .section ".toc","aw" >>> ^ >>> locore64_simplified.S:47:2: warning: DWARF2 only supports one = section per compilation unit >>> .section ".opd","aw" >>> ^ >>>=20 >>> (buildkernel gets such messages.) >>>=20 >>>=20 >>> I expect I can simplify the .S code more than I have so far but >>> I figured I'd report the discovery of the choice FreeBSD needs >>> to make for powerpc64 for if llvm changes are to be required >>> vs. not. >>=20 >> The following should be a list of the places that adding @toc usage >> would fix some things for using clang 3.9.1 to target powerpc64: >>=20 >> # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more >> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol >> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on = symbol >>=20 >> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report >> on missing @toc 's. >>=20 >> But, of course, if some sections of code are conditionally compiled = and >> excluded above they would not be listed. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > _______________________________________________ > 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-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-ppc@freebsd.org Sun Jan 8 14:44:04 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECA09CA5AD0; Sun, 8 Jan 2017 14:44:04 +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 337961A39; Sun, 8 Jan 2017 14:44:03 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 4A12A12CB9F; Sun, 8 Jan 2017 15:41:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1483886493; bh=vCgzSIINqOzze7yLf5Yv6wqJATaDHyKhrezxsWxQI2o=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=b71/oSenmf+JqRJzFsJikcg9xVdabDCA2uX9/cPOfy2fgGZacr/o3siNMxnzV+4G0 e59fv1la2YSyjDLkFfXzHdtJRgLt3a9scCf/7BVcQUNS7sG5Acv7BabZH04jq7qcYf OsMxDHflX0/V0xF3LjRjQH8GV9kUa1QwIQR+4TCo= Date: Sun, 8 Jan 2017 15:41:33 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML , Ed Maste , Mark Linimon Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] Message-ID: <20170108144133.GA19529@vlakno.cz> References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@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.2 (2016-11-26) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 14:44:05 -0000 Mark, Would you be interested in trying lld? It has some support for ppc/ppc64, w= hich is probably quite incomplete but it would be nice to know what exactly is missing. We also have some people (emaste@, davide@) that have non-trivial lld knowl= edge so perhaps progress can be achieved on this side easily? Roman On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: > [I forgot to indicate that I still can not use the system bootstrapped > ld command and so there is a reason that I used devel/powerpc64-binutils.] >=20 > On 2017-Jan-8, at 2:24 AM, Mark Millard wrote: >=20 > > On 2017-Jan-8, at 1:03 AM, Roman Divacky wrote: > >=20 > >> I think we should add the @toc notations to all the places where it's = needed. > >> Can you submit such a patch (perhaps with the one for adding 0 to the = cmp > >> instruction) so they can be committed to FreeBSD repo? > >=20 > > In order to test I added @toc to each of the 10 instructions instead > > of adjusting the macros so that instructions would automatically > > get the notation but other (what are now) TOC_REF(...) usage would > > not that should not. > >=20 > > I suspect Nathan and Justin might prefer a more automatic > > alternative so that TOC_REF(...) in an instruction would > > be sufficient without an explicit @toc in the instruction. > >=20 > > I'll see about switching to such code before providing a > > patch. I'd include the "0, " update to the cmp instruction. > >=20 > > But adding @toc's in those instructions (with prior workarounds > > as well) did allow me to build a bootable system based on using > > devel/powerpc64-binutils and clang 3.9.1 for both buildworld > > and buildkernel --still using clang's internal assembler. > >=20 > > One issue is that clang does not support (or need) the > > -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 > > requires it. For sys/modules/zfs/Makefile my source > > currently does not support gcc 4.2.1 without editing. > > As I remember devel/powerpc64-gcc > > (devel/powerpc64-xtoolchain-gcc) does not require the > > -mminimal-toc either. But devel/powerpc64-gcc does > > allow -mminimal-toc so it can be a clang vs. gcc based > > choice. > >=20 > > I might also deal with that before providing patches. > >=20 > > Note: -mlongcall was also not needed nor used for clang. > > (Still used for gcc.) > >=20 > > sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 > > and -Wa,-mppc64bridge that I eliminated (they messed up > > 32-bit powerpc builds) but I've no way to test kboot that > > I know of. This patch might be rejected. > >=20 > > Remember that I got this far in part by using your partial > > e500-instructions patch. I can provide my variant that > > is a diff with -r311147 instead of an older place in the > > history. But it would be incomplete coverage of those 2 > > instructions in clang. > >=20 > > Also I build with a workaround for PowerMac G5 boot > > reliability since OpenFirmware and FreeBSD interact > > badly at times on PowerMac G5's. This I would not > > provide as it is PowerMac G5 specific. > >=20 > >> If gnu as warns and llvm assembler does the wrong thing without @toc a= nd both > >> do the correct thing with @toc I think it's an obvious decision. > >=20 > > My choice would be to supply the @toc notation in some way, > > not necessarily the form I used for the initial test. > >=20 > >> Also, with all these changes. Does clang compiled kernel boot? > >=20 > > The PowerMac G5 so-called "Quad Core" that I currently have access > > to is now running from buildworld and buildkernel based on > > devel/powerpc64-binutils and clang 3.9.1 : > >=20 > > Copyright (c) 1992-2017 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 > > markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/pow= erpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc > > FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on L= LVM 3.9.1) > > . . . > >=20 > > # uname -apKU > > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan = 7 16:55:01 PST 2017 markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_alt= binutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc = powerpc64 1200019 1200019 > >=20 > > I've built about a dozen ports on it after booting but I've not > > done a self-hosted buildworld buildkernel yet. > >=20 > > [Note: Anything dependent on throwing C++ exceptions in > > code generated by clang++ 3.9.1 is broken.] >=20 > I should have been explicit: >=20 > I still can not use the system bootstrapped ld command > and such binutils for buildkernel and so there is a > reason that I used devel/powerpc64-binutils instead. >=20 > Thus even with my patches clang 3.9.1 would not be ready > for general use or for a default way of building. I > have to have a tailored SRC_ENV_CONF file or the like > still --and a port built and installed. >=20 > [On a powerpc64 system devel/binutils could be used.] >=20 > There is also the issue with throwing C++ exceptions > in code when clang 3.9.1 was the code generator used. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: > > [Top post about FreeBSD bugzilla 215819 and llvm bugzilla > > 31574 submittals for the issue involved.] > >=20 > > My guess is that FreeBSD will view this as a kernel > > source code issue and not as a toolchain issue. But > > it is only a guess on my part. > >=20 > >=20 > > I have submitted llvm bugzilla 31574 for this issue. It > > includes example .S file content that shows the "problem" > > in the generated .o file (form FreeBSD's view point). > > (I've no clue how llvm views its criteria relative to this > > mismatch with gcc/binutils.) > >=20 > > Because FreeBSD source code changes (being explicit about > > @toc) avoid the distinction between clang and gcc/binutils > > I've not added 31574 to the Depends on list for llvm 25780 > > (the FreeBSD system compiler issues META entry in llvm). > >=20 > > Someone with official status for FreeBSD could add 31574 to > > llvm's 25780 if FreeBSD wants to push llvm to match > > gcc/binutils for "@toc notation missing". > >=20 > > Otherwise this is a kernel source code issue (as I would > > guess) and not a toolchain issue. > >=20 > > Ed Maste or someone like that likely would make the final > > decision. > >=20 > >=20 > > I've added to FreeBSD Bugzilla 215819 the new information, > > including the simple example .S file content that shows the > > problem in the generated .o file. (Comments #3 and #4 > > have the new material.) > >=20 > > My guess is that FreeBSD Bugzilla 215819 should no longer > > be assigned to freebsd-toolchain@FreeBSD.org . Instead it > > would be a powerpc64 kernel source code issue if I'm right. > >=20 > > Ed Maste or someone like that likely would make this final > > decision as well. > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net > >=20 > > On 2017-Jan-7, at 3:12 PM, Mark Millard wrote: > >=20 > >> [I've supplied a list of places that adding @toc notation should > >> make clang 3.9.1 targeting powerpc64 do the right thing for > >> this issue.] > >>=20 > >> On 2017-Jan-7, at 2:07 PM, Mark Millard wrote: > >>=20 > >>> On 2017-Jan-7, at 12:51 AM, Roman Divacky wro= te: > >>>=20 > >>>> That's a great progress. Can you produce minimal self contained test= case that > >>>> exhibits this bug? And submit it to llvm bugzilla? > >>>>=20 > >>>> Also, clang3.9 defaults to using it's own internal asm, what happens= if you > >>>> add -no-integrated-as to CFLAGS and recompile the kernel? That shoul= d remove > >>>> this llvm assembly problem. Does it boot? > >>>>=20 > >>>> Thanks Mark, really great progress. > >>>>=20 > >>>> Roman > >>>=20 > >>> In attempting this I found how to control the behavior based on > >>> the assembler notation @toc being missing vs. being present. > >>>=20 > >>> If llvm should change is strongly tied to llvm's criteria for > >>> gcc compatibility relative to filling-in/defaulting omitted > >>> @toc's in the assembler notation. > >>>=20 > >>> FreeBSD has the option of always being explicit with @toc in order > >>> to avoid differences in handling of omitted notation. > >>>=20 > >>> So I've no clue if FreebSD wants to claim that a llvm change > >>> is a requirement for using clang as the powerpc64 system compiler. > >>>=20 > >>> [The issue of the distinction is submittable to llvm either way.] > >>>=20 > >>> Details. . . > >>>=20 > >>> For: > >>>=20 > >>> .section ".toc","aw" > >>> tmpstk.L: .tc tmpstk[TC],tmpstk > >>> . . . > >>> /* Set up the stack pointer */ > >>> ld %r1,tmpstk.L(%r2) > >>>=20 > >>> using devel/powerpc64-gcc gets: > >>>=20 > >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 > >=20 > >>=20 > >>> = locore64_simplified.S > >>> locore64_simplified.S: Assembler messages: > >>> locore64_simplified.S:80: Warning: assuming @toc on symbol > >>>=20 > >>> and produces (with R_PPC64_TOC16_DS for .toc): > >>>=20 > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o > >>>=20 > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>>=20 > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_TOC16_DS .toc > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>>=20 > >>>=20 > >>> By contrast clang is silent (cross compiler used): > >>>=20 > >>> # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/u= sr/bin/cc \ = = -target powerpc64-unk= nown-freebsd12.0 \ = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/= powerpc.powerpc64/usr/src/tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/b= in \ = =20 >=20 > >=20 > >>=20 > >>> = -c \ = = = -x as= sembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S > >>>=20 > >>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: > >>>=20 > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o |= more = = =20 > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>>=20 > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_ADDR16_DS .toc > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>>=20 > >>>=20 > >>>=20 > >>> But for: > >>>=20 > >>> .section ".toc","aw" > >>> tmpstk.L: .tc tmpstk[TC],tmpstk > >>> . . . > >>> /* Set up the stack pointer */ > >>> ld %r1,tmpstk.L@toc(%r2) > >>>=20 > >>> (note the @toc notation) both compilers agree and use > >>> R_PPC64_TOC16_DS for the .toc: > >>>=20 > >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 > >=20 > >>=20 > >>> = locore64_simplified.S > >>>=20 > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o |= more = = =20 > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>>=20 > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_TOC16_DS .toc > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>>=20 > >>>=20 > >>> # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/u= sr/bin/cc \ = = -target powerpc64-unk= nown-freebsd12.0 \ = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/= powerpc.powerpc64/usr/src/tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/b= in \ = =20 >=20 > >=20 > >>=20 > >>> = -c \ = = = -x as= sembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S > >>>=20 > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o |= more = = =20 > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>>=20 > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_TOC16_DS .toc > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>>=20 > >>>=20 > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE=20 > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>>=20 > >>>=20 > >>>=20 > >>> I omitted "-f -gdwarf-2" to simplify things but with such > >>> clang complains about: > >>>=20 > >>> locore64_simplified.S:36:2: warning: DWARF2 only supports one section= per compilation unit > >>> .section ".toc","aw" > >>> ^ > >>> locore64_simplified.S:47:2: warning: DWARF2 only supports one section= per compilation unit > >>> .section ".opd","aw" > >>> ^ > >>>=20 > >>> (buildkernel gets such messages.) > >>>=20 > >>>=20 > >>> I expect I can simplify the .S code more than I have so far but > >>> I figured I'd report the discovery of the choice FreeBSD needs > >>> to make for powerpc64 for if llvm changes are to be required > >>> vs. not. > >>=20 > >> The following should be a list of the places that adding @toc usage > >> would fix some things for using clang 3.9.1 to target powerpc64: > >>=20 > >> # grep "@toc[^b]" /root/sys_typescripts/typescript_make_powerpc64vtsc_= nodebug_incl_clang_xtoolchain_kernel-amd64-host-2017-01-03:23:48:41 | more > >> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on sym= bol > >> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on = symbol > >> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on = symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on sy= mbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on sy= mbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on sy= mbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on sy= mbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on sy= mbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on sy= mbol > >> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on = symbol > >>=20 > >> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to r= eport > >> on missing @toc 's. > >>=20 > >> But, of course, if some sections of code are conditionally compiled and > >> excluded above they would not be listed. > >>=20 > >> =3D=3D=3D > >> Mark Millard > >> markmi at dsl-only.net > >=20 > > _______________________________________________ > > freebsd-toolchain@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd= =2Eorg" >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.o= rg" From owner-freebsd-ppc@freebsd.org Sun Jan 8 16:45:51 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9461CA5A66 for ; Sun, 8 Jan 2017 16:45:51 +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 98E621AFF for ; Sun, 8 Jan 2017 16:45:51 +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 v08GjpJq017802 for ; Sun, 8 Jan 2017 16:45:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Sun, 08 Jan 2017 16:45:51 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 16:45:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #15 from Justin Hibbits --- Hi Curtis, I'm using FreeBSD 12-CURRENT, as of September (r305820). Regarding /etc/libmap.conf, it should be unnecessary when building with USE_GCC=3Dyes, because the ports framework will set -rpath and other comman= d line arguments appropriately. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 20:15:34 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10745CA5A45 for ; Sun, 8 Jan 2017 20:15:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3D3719C8 for ; Sun, 8 Jan 2017 20:15: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 v08KFXMr099962 for ; Sun, 8 Jan 2017 20:15:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Sun, 08 Jan 2017 20:15:34 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:15:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #16 from Justin Hibbits --- Hi Curtis, I just checked libstdc++.a and libstdc++.so in /usr/local/lib/gcc49, and neither have the symbols *@GLIBCXX_3.4.15, the symbols are naked: 0000000000079920 t 00000612.plt_call._ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm 000000000017b410 D _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm 000000000017b428 D _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm 0000000000126d98 r _ZZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEmE10__fast_bkt It does have an absolute symbol of GLIBCXX_3.4.15 0000000000000000 A GLIBCXX_3.4.15 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 20:18:05 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D2ACCA5BA7 for ; Sun, 8 Jan 2017 20:18:05 +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 5C9E71A16 for ; Sun, 8 Jan 2017 20:18:05 +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 v08KI4hO003117 for ; Sun, 8 Jan 2017 20:18:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Sun, 08 Jan 2017 20:18:05 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:18:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #17 from Justin Hibbits --- Created attachment 178631 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178631&action= =3Dedit Verbose log of libreoffice 5.2.4 build Here's the full verbose log (modified editors/libreoffice/Makefile to add a "MAKE_ENV +=3D GMAKE_OPTIONS=3D'VERBOSE=3D1'" line) The offending line was actually: [build LNK] Executable/oosplash S=3D/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2 && I=3D$S/instdir && W=3D$S/workdir && gcc49 -Wl,-z,origin '-Wl,-rpath,$OR= IGIN' -Wl,-rpath-link,$I/program -fstack-protector-strong -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -Wl,--hash-style=3Dgnu=20 -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib=20 -L$I/program -L$I/program -L/usr/local/lib -Wl,-rpath=3D/usr/local/lib/gcc= 49 -L/usr/local/lib/gcc49 -L/usr/local/lib -R/usr/local/lib $W/CObject/desktop/unx/source/args.o $W/CObject/desktop/unx/source/file_image_unx.o $W/CObject/desktop/unx/source/pagein.o $W/CObject/desktop/unx/source/splash= x.o $W/CObject/desktop/unx/source/start.o -Wl,--start-group -lXinerama= =20 -lX11 -L/usr/local/lib -lpng16 -Wl,--end-group -Wl,--no-as-needed -luno_s= al -o $I/program/oosplash --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 20:20:00 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9F89CA5D10 for ; Sun, 8 Jan 2017 20:20: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 A995F1A63 for ; Sun, 8 Jan 2017 20:20: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 v08KK0qp005466 for ; Sun, 8 Jan 2017 20:20:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Sun, 08 Jan 2017 20:20:00 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:20:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #18 from Justin Hibbits --- (In reply to Justin Hibbits from comment #16) Of course I meant both GLIBCXX_3.4.15 and GLIBCXX_3.4.18 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Jan 8 20:23:18 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B65BCA6106 for ; Sun, 8 Jan 2017 20:23:18 +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 882681E0F for ; Sun, 8 Jan 2017 20:23:18 +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 v08KNHnr018694 for ; Sun, 8 Jan 2017 20:23:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 201612] print/texlive-base fails on powerpc Date: Sun, 08 Jan 2017 20:23:17 +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 Many People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hrs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? 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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:23:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201612 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhibbits@FreeBSD.org --- Comment #1 from Justin Hibbits --- I believe this has been overcome by events (submitter, please advise?). I'= ve successfully built texlive-base on powerpc64, but it now requires USE_GCC= =3Dyes, because it depends on devel/icu, see bug 215770) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Jan 9 00:23:12 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1116CA349A for ; Mon, 9 Jan 2017 00:23:12 +0000 (UTC) (envelope-from admin@x253.save85off.com) Received: from x253.save85off.com (x253.save85off.com [43.240.238.253]) by mx1.freebsd.org (Postfix) with ESMTP id 723451A61 for ; Mon, 9 Jan 2017 00:23:12 +0000 (UTC) (envelope-from admin@x253.save85off.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=save85off; d=x253.save85off.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin@x253.save85off.com; bh=ELT3Bp2fTXgzBFpWno2BrnsySP4=; b=TUTqA9ArHf/NR59oyqCibjvq3jn6k8shhgkmQsRxE77dH4hbtidsXTyuh3ml7Q0QIOiSJ6lPj3BA zXzAj13maLwJ65hEoJ9tRWvqGpXnKVgWiGGSHcBfj25TXEbRRowkIun3T8c/9wFZW4LSdKUw1smu IXxZ4afYC8vkwUTkqhw= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=save85off; d=x253.save85off.com; b=KWbmSbeNHZ20cN3P1Ldx+l9qVVxNix4tOCynSmp5B1l65WPillZImcmy6b2yxHmqHjOBI0H3Kipt +lAjBEXE7zafIK8sBYmZx4MvLvbaol3wXEPXe9RKGB4WKK+FUPnOnXtVIRwepYZ9GrZd2AWHgOZ6 w+UxUWL5Bj4UwDaf4NE=; From: "UGG Australia Boots" To: freebsd-ppc@freebsd.org Date: 9 Jan 2017 08:12:52 +0800 Subject: New Year Promotion:50% off everything + a bonus offer win 123$ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 00:23:12 -0000 From owner-freebsd-ppc@freebsd.org Mon Jan 9 00:40:13 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C50ACA28E4 for ; Mon, 9 Jan 2017 00:40:13 +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 3C4101DFD for ; Mon, 9 Jan 2017 00:40:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17993 invoked from network); 9 Jan 2017 00:40:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Jan 2017 00:40:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sun, 08 Jan 2017 19:40:05 -0500 (EST) Received: (qmail 22453 invoked from network); 9 Jan 2017 00:40:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Jan 2017 00:40:05 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B8DB1EC7888; Sun, 8 Jan 2017 16:40:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <20170108144133.GA19529@vlakno.cz> Date: Sun, 8 Jan 2017 16:40:04 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> <20170108144133.GA19529@vlakno.cz> To: Roman Divacky , Justin Hibbits , Ed Maste , Nathan Whitehorn X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 00:40:13 -0000 [I've not tried lldb yet but I have good news. . .] Well it turns out I was wrong: after the @toc changes (now in the TOC_REF(...) macro instead of per instruction) I can boot a kernel built using the bootstrap system binutils and clang as well. devel/powerpc64-binutils or the like is not required. It looks like bugzilla 215821 is wrong/redundant and 215819 actually covers the issue. I will likely close 215821 after I've played around some more. I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc = 4.2.1 as I have things. clang 3.9.1 based builds do not handle throwing C++ exceptions. lib32 does not work for devel/powerpc64-gcc based builds. As stands I have head -r311147 with: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c (Not relevant) M /usr/src/sys/ddb/db_script.c (Not relevant) M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/aim/trap_subr32.S M /usr/src/sys/powerpc/include/asm.h M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant) The various KERNCONF's include standard ones then adjust things. They are not otherwise relevant. Notes on the differences ("M" lines): [I do not have a context to test powerpc's kboot or uboot for powerpc or powerpc64: only PowerMacs. Those Makefile changes were based on avoiding build errors that occurred before the change (long ago). I've not gone back through the armv6(/v7) and arm64 builds recently but historically they have worked on the rpi2, bpim3, and pine64 with the boot/uboot/Makefile.inc change in place.] llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s incomplete patch for the e500 instructions. It was sufficient to let me continue. The various Makefile*'s and *.mk's deal with: -mlongcall (gcc) vs. not (clang) -m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new) -mcpu=3Dpowerpc64 and -Wa,-mppc64bridge in a Makefile (kboot) that TARGET_ARCH=3Dpowerpc tried to build and failed: delete the usage of these options. (No test validation of built kboot result!) -Wa,many for gcc vs. no-such for clang sys/conf/kern.mk deals with: -mllvm -disable-ppc-float-in-variadic=3Dtrue (older clang) vs. -msoft-float (newer clang) sys/modules/zfs/Makefile deals with: -mminimial-toc (gcc) vs. no-such (clang) sys/ddb/db_main.c and sys/ddb/db_script.c : These would not be included. (They set up to execute a built-in default script so I get information for early boot issues from before ddb takes input.) sys/powerpc/aim/trap_subr32.S deals with: Have a cmp instruction be explicit by adding a "0, ". (This is a TARGET_ARCH=3Dpowerpc issue, not a TARGET_ARCH=3Dpowerpc64 issue.) sys/powerpc/include/asm.h deals with: Have TOC_REF(...) also include @toc in the notation that results. Have a TOC_NAME_FOR_REF(...) that only adds the .L to the name passed in and use it where appropriate. sys/powerpc/ofw/ofw_machdep.c : This would not be included. (It is a PowerMac G5 specific workaround for a openfirmware vs. FreeBSD conflict that makes booting unreliable for standard FreeBSD builds.) The details that are not driven by PowerMac G5 specifics look like: 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 311147) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) @@ -2336,6 +2336,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 Index: /usr/src/lib/csu/powerpc64/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/lib/csu/powerpc64/Makefile (revision 311147) +++ /usr/src/lib/csu/powerpc64/Makefile (working copy) @@ -5,19 +5,20 @@ SRCS=3D crt1.c crti.S crtn.S OBJS=3D ${SRCS:N*.h:R:S/$/.o/g} OBJS+=3D Scrt1.o gcrt1.o +.include +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -I${.CURDIR}/../common \ -I${.CURDIR}/../../libc/include \ -mlongcall +.else +CFLAGS+=3D -I${.CURDIR}/../common \ + -I${.CURDIR}/../../libc/include +.endif =20 # XXX: See the log for r232932 as to why the above -mlongcall is = needed. Since # clang doesn't support -mlongcall, and testing shows a clang linked = with a # clang-built csu segfaults, this must currently be compiled with gcc. = Once # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. -.include -.if ${COMPILER_TYPE} !=3D "gcc" -CC:=3D gcc -COMPILER_TYPE:=3D gcc -.endif =20 FILES=3D ${OBJS} FILESMODE=3D ${LIBMODE} Index: /usr/src/sys/boot/ofw/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/ofw/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) @@ -2,7 +2,7 @@ =20 .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif =20 .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/powerpc/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) @@ -2,6 +2,7 @@ =20 .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif =20 .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/kboot/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/boot/powerpc/kboot/Makefile (revision 311147) +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) @@ -68,8 +68,6 @@ LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a .endif =20 -CFLAGS+=3D -mcpu=3Dpowerpc64 - # Always add MI sources .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern .include "${.CURDIR}/../../common/Makefile.inc" @@ -85,9 +83,6 @@ =20 LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc =20 -# 64-bit bridge extensions -CFLAGS+=3D -Wa,-mppc64bridge - # Pull in common loader code #.PATH: ${.CURDIR}/../../ofw/common #.include "${.CURDIR}/../../ofw/common/Makefile.inc" Index: /usr/src/sys/boot/uboot/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/uboot/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) @@ -2,7 +2,7 @@ =20 .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif =20 .include "../Makefile.inc" Index: /usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/Makefile.powerpc (revision 311147) +++ /usr/src/sys/conf/Makefile.powerpc (working copy) @@ -39,7 +39,11 @@ # Force __SPE__, since the builtin will be removed later with -mno-spe CFLAGS+=3D -mabi=3Dspe -D__SPE__ .endif +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif =20 # Build position-independent kernel CFLAGS+=3D -fPIC Index: /usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kern.mk (revision 311147) +++ /usr/src/sys/conf/kern.mk (working copy) @@ -162,7 +162,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kmod.mk (revision 311147) +++ /usr/src/sys/conf/kmod.mk (working copy) @@ -147,8 +147,12 @@ .endif =20 .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif =20 .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls 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 311147) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,16 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS =20 + .if ${MACHINE_ARCH} =3D=3D "powerpc64" +.include +.if ${COMPILER_TYPE} =3D=3D "gcc" +# gcc421 requires the -mminimal-toc . +# But clang 3.9.1 disallows it and does not need it. +# more modern gcc's allow it. CFLAGS+=3D-mminimal-toc .endif +.endif =20 .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 Index: /usr/src/sys/powerpc/aim/trap_subr32.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/aim/trap_subr32.S (revision 311147) +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) @@ -406,7 +406,7 @@ mtctr %r1 /* load counter */ im1: lwzu %r1, 8(%r2) /* get next pte */ - cmp 0, %r1, %r3 /* see if found pte */ + cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, im1 /* dec count br if cmp ne and if * count not zero */ bne instr_sec_hash /* if not found set up second = hash Index: /usr/src/sys/powerpc/include/asm.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/include/asm.h (revision 311147) +++ /usr/src/sys/powerpc/include/asm.h (working copy) @@ -89,10 +89,11 @@ name: =20 #ifdef __powerpc64__ -#define TOC_REF(name) __CONCAT(.L,name) +#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name) +#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc #define TOC_ENTRY(name) \ .section ".toc","aw"; \ - TOC_REF(name): \ + TOC_NAME_FOR_REF(name): \ .tc name[TC],name #endif =20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 6:41 AM, Roman Divacky wrote: Mark, Would you be interested in trying lld? It has some support for = ppc/ppc64, which is probably quite incomplete but it would be nice to know what exactly = is missing. We also have some people (emaste@, davide@) that have non-trivial lld = knowledge so perhaps progress can be achieved on this side easily? Roman On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: > [I forgot to indicate that I still can not use the system bootstrapped > ld command and so there is a reason that I used = devel/powerpc64-binutils.] >=20 > On 2017-Jan-8, at 2:24 AM, Mark Millard = wrote: >=20 >> On 2017-Jan-8, at 1:03 AM, Roman Divacky = wrote: >>=20 >>> I think we should add the @toc notations to all the places where = it's needed. >>> Can you submit such a patch (perhaps with the one for adding 0 to = the cmp >>> instruction) so they can be committed to FreeBSD repo? >>=20 >> In order to test I added @toc to each of the 10 instructions instead >> of adjusting the macros so that instructions would automatically >> get the notation but other (what are now) TOC_REF(...) usage would >> not that should not. >>=20 >> I suspect Nathan and Justin might prefer a more automatic >> alternative so that TOC_REF(...) in an instruction would >> be sufficient without an explicit @toc in the instruction. >>=20 >> I'll see about switching to such code before providing a >> patch. I'd include the "0, " update to the cmp instruction. >>=20 >> But adding @toc's in those instructions (with prior workarounds >> as well) did allow me to build a bootable system based on using >> devel/powerpc64-binutils and clang 3.9.1 for both buildworld >> and buildkernel --still using clang's internal assembler. >>=20 >> One issue is that clang does not support (or need) the >> -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 >> requires it. For sys/modules/zfs/Makefile my source >> currently does not support gcc 4.2.1 without editing. >> As I remember devel/powerpc64-gcc >> (devel/powerpc64-xtoolchain-gcc) does not require the >> -mminimal-toc either. But devel/powerpc64-gcc does >> allow -mminimal-toc so it can be a clang vs. gcc based >> choice. >>=20 >> I might also deal with that before providing patches. >>=20 >> Note: -mlongcall was also not needed nor used for clang. >> (Still used for gcc.) >>=20 >> sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 >> and -Wa,-mppc64bridge that I eliminated (they messed up >> 32-bit powerpc builds) but I've no way to test kboot that >> I know of. This patch might be rejected. >>=20 >> Remember that I got this far in part by using your partial >> e500-instructions patch. I can provide my variant that >> is a diff with -r311147 instead of an older place in the >> history. But it would be incomplete coverage of those 2 >> instructions in clang. >>=20 >> Also I build with a workaround for PowerMac G5 boot >> reliability since OpenFirmware and FreeBSD interact >> badly at times on PowerMac G5's. This I would not >> provide as it is PowerMac G5 specific. >>=20 >>> If gnu as warns and llvm assembler does the wrong thing without @toc = and both >>> do the correct thing with @toc I think it's an obvious decision. >>=20 >> My choice would be to supply the @toc notation in some way, >> not necessarily the form I used for the initial test. >>=20 >>> Also, with all these changes. Does clang compiled kernel boot? >>=20 >> The PowerMac G5 so-called "Quad Core" that I currently have access >> to is now running from buildworld and buildkernel based on >> devel/powerpc64-binutils and clang 3.9.1 : >>=20 >> Copyright (c) 1992-2017 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 >> = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc >> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) >> . . . >>=20 >> # uname -apKU >> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat = Jan 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 >>=20 >> I've built about a dozen ports on it after booting but I've not >> done a self-hosted buildworld buildkernel yet. >>=20 >> [Note: Anything dependent on throwing C++ exceptions in >> code generated by clang++ 3.9.1 is broken.] >=20 > I should have been explicit: >=20 > I still can not use the system bootstrapped ld command > and such binutils for buildkernel and so there is a > reason that I used devel/powerpc64-binutils instead. >=20 > Thus even with my patches clang 3.9.1 would not be ready > for general use or for a default way of building. I > have to have a tailored SRC_ENV_CONF file or the like > still --and a port built and installed. >=20 > [On a powerpc64 system devel/binutils could be used.] >=20 > There is also the issue with throwing C++ exceptions > in code when clang 3.9.1 was the code generator used. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: >> [Top post about FreeBSD bugzilla 215819 and llvm bugzilla >> 31574 submittals for the issue involved.] >>=20 >> My guess is that FreeBSD will view this as a kernel >> source code issue and not as a toolchain issue. But >> it is only a guess on my part. >>=20 >>=20 >> I have submitted llvm bugzilla 31574 for this issue. It >> includes example .S file content that shows the "problem" >> in the generated .o file (form FreeBSD's view point). >> (I've no clue how llvm views its criteria relative to this >> mismatch with gcc/binutils.) >>=20 >> Because FreeBSD source code changes (being explicit about >> @toc) avoid the distinction between clang and gcc/binutils >> I've not added 31574 to the Depends on list for llvm 25780 >> (the FreeBSD system compiler issues META entry in llvm). >>=20 >> Someone with official status for FreeBSD could add 31574 to >> llvm's 25780 if FreeBSD wants to push llvm to match >> gcc/binutils for "@toc notation missing". >>=20 >> Otherwise this is a kernel source code issue (as I would >> guess) and not a toolchain issue. >>=20 >> Ed Maste or someone like that likely would make the final >> decision. >>=20 >>=20 >> I've added to FreeBSD Bugzilla 215819 the new information, >> including the simple example .S file content that shows the >> problem in the generated .o file. (Comments #3 and #4 >> have the new material.) >>=20 >> My guess is that FreeBSD Bugzilla 215819 should no longer >> be assigned to freebsd-toolchain@FreeBSD.org . Instead it >> would be a powerpc64 kernel source code issue if I'm right. >>=20 >> Ed Maste or someone like that likely would make this final >> decision as well. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2017-Jan-7, at 3:12 PM, Mark Millard = wrote: >>=20 >>> [I've supplied a list of places that adding @toc notation should >>> make clang 3.9.1 targeting powerpc64 do the right thing for >>> this issue.] >>>=20 >>> On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >>>=20 >>>> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>>>=20 >>>>> That's a great progress. Can you produce minimal self contained = test case that >>>>> exhibits this bug? And submit it to llvm bugzilla? >>>>>=20 >>>>> Also, clang3.9 defaults to using it's own internal asm, what = happens if you >>>>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>>>> this llvm assembly problem. Does it boot? >>>>>=20 >>>>> Thanks Mark, really great progress. >>>>>=20 >>>>> Roman >>>>=20 >>>> In attempting this I found how to control the behavior based on >>>> the assembler notation @toc being missing vs. being present. >>>>=20 >>>> If llvm should change is strongly tied to llvm's criteria for >>>> gcc compatibility relative to filling-in/defaulting omitted >>>> @toc's in the assembler notation. >>>>=20 >>>> FreeBSD has the option of always being explicit with @toc in order >>>> to avoid differences in handling of omitted notation. >>>>=20 >>>> So I've no clue if FreebSD wants to claim that a llvm change >>>> is a requirement for using clang as the powerpc64 system compiler. >>>>=20 >>>> [The issue of the distinction is submittable to llvm either way.] >>>>=20 >>>> Details. . . >>>>=20 >>>> For: >>>>=20 >>>> .section ".toc","aw" >>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>> . . . >>>> /* Set up the stack pointer */ >>>> ld %r1,tmpstk.L(%r2) >>>>=20 >>>> using devel/powerpc64-gcc gets: >>>>=20 >>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>>=20 >>>> = locore64_simplified.S >>>> locore64_simplified.S: Assembler messages: >>>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>>=20 >>>> and produces (with R_PPC64_TOC16_DS for .toc): >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>>>=20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>> By contrast clang is silent (cross compiler used): >>>>=20 >>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>>=20 >>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>=20 >>>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>>=20 >>>> But for: >>>>=20 >>>> .section ".toc","aw" >>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>> . . . >>>> /* Set up the stack pointer */ >>>> ld %r1,tmpstk.L@toc(%r2) >>>>=20 >>>> (note the @toc notation) both compilers agree and use >>>> R_PPC64_TOC16_DS for the .toc: >>>>=20 >>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>>=20 >>>> = locore64_simplified.S >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>>=20 >>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>>=20 >>>> I omitted "-f -gdwarf-2" to simplify things but with such >>>> clang complains about: >>>>=20 >>>> locore64_simplified.S:36:2: warning: DWARF2 only supports one = section per compilation unit >>>> .section ".toc","aw" >>>> ^ >>>> locore64_simplified.S:47:2: warning: DWARF2 only supports one = section per compilation unit >>>> .section ".opd","aw" >>>> ^ >>>>=20 >>>> (buildkernel gets such messages.) >>>>=20 >>>>=20 >>>> I expect I can simplify the .S code more than I have so far but >>>> I figured I'd report the discovery of the choice FreeBSD needs >>>> to make for powerpc64 for if llvm changes are to be required >>>> vs. not. >>>=20 >>> The following should be a list of the places that adding @toc usage >>> would fix some things for using clang 3.9.1 to target powerpc64: >>>=20 >>> # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more >>> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc = on symbol >>> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc = on symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc = on symbol >>>=20 >>> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report >>> on missing @toc 's. >>>=20 >>> But, of course, if some sections of code are conditionally compiled = and >>> excluded above they would not be listed. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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-ppc@freebsd.org Mon Jan 9 05:34:48 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FD19CA51E4 for ; Mon, 9 Jan 2017 05:34:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-11.reflexion.net [208.70.210.11]) (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 EFB9715B2 for ; Mon, 9 Jan 2017 05:34:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7394 invoked from network); 9 Jan 2017 05:35:04 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Jan 2017 05:35:04 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 09 Jan 2017 00:34:56 -0500 (EST) Received: (qmail 21642 invoked from network); 9 Jan 2017 05:34:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Jan 2017 05:34:56 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 6C42FEC8B81; Sun, 8 Jan 2017 21:34:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> Date: Sun, 8 Jan 2017 21:34:39 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <964800DA-213A-4855-A5E7-8C62823E55D5@dsl-only.net> References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> <20170108144133.GA19529@vlakno.cz> <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> To: Roman Divacky , Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 05:34:48 -0000 I'll note that: Bug 214855 - head -r309179 TARGET_ARCH=3Dpowerpc64 clang 3.9.0 based = cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 = [FreeBSD] 2007-07-03 internal error means that I can not use the bootstrap binutils to do buildworld for = powerpc64. I've confirmed that it still happens in -r311147 . So to span both buildkernel and buildworld does require = devel/powerpc64-binutils or the like for TARGET_ARCH=3Dpowerpc64 . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 4:40 PM, Mark Millard wrote: [I've not tried lldb yet but I have good news. . .] Well it turns out I was wrong: after the @toc changes (now in the TOC_REF(...) macro instead of per instruction) I can boot a kernel built using the bootstrap system binutils and clang as well. devel/powerpc64-binutils or the like is not required. It looks like bugzilla 215821 is wrong/redundant and 215819 actually covers the issue. I will likely close 215821 after I've played around some more. I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc = 4.2.1 as I have things. clang 3.9.1 based builds do not handle throwing C++ exceptions. lib32 does not work for devel/powerpc64-gcc based builds. As stands I have head -r311147 with: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c (Not relevant) M /usr/src/sys/ddb/db_script.c (Not relevant) M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/aim/trap_subr32.S M /usr/src/sys/powerpc/include/asm.h M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant) The various KERNCONF's include standard ones then adjust things. They are not otherwise relevant. Notes on the differences ("M" lines): [I do not have a context to test powerpc's kboot or uboot for powerpc or powerpc64: only PowerMacs. Those Makefile changes were based on avoiding build errors that occurred before the change (long ago). I've not gone back through the armv6(/v7) and arm64 builds recently but historically they have worked on the rpi2, bpim3, and pine64 with the boot/uboot/Makefile.inc change in place.] llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s incomplete patch for the e500 instructions. It was sufficient to let me continue. The various Makefile*'s and *.mk's deal with: -mlongcall (gcc) vs. not (clang) -m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new) -mcpu=3Dpowerpc64 and -Wa,-mppc64bridge in a Makefile (kboot) that TARGET_ARCH=3Dpowerpc tried to build and failed: delete the usage of these options. (No test validation of built kboot result!) -Wa,many for gcc vs. no-such for clang sys/conf/kern.mk deals with: -mllvm -disable-ppc-float-in-variadic=3Dtrue (older clang) vs. -msoft-float (newer clang) sys/modules/zfs/Makefile deals with: -mminimial-toc (gcc) vs. no-such (clang) sys/ddb/db_main.c and sys/ddb/db_script.c : These would not be included. (They set up to execute a built-in default script so I get information for early boot issues from before ddb takes input.) sys/powerpc/aim/trap_subr32.S deals with: Have a cmp instruction be explicit by adding a "0, ". (This is a TARGET_ARCH=3Dpowerpc issue, not a TARGET_ARCH=3Dpowerpc64 issue.) sys/powerpc/include/asm.h deals with: Have TOC_REF(...) also include @toc in the notation that results. Have a TOC_NAME_FOR_REF(...) that only adds the .L to the name passed in and use it where appropriate. sys/powerpc/ofw/ofw_machdep.c : This would not be included. (It is a PowerMac G5 specific workaround for a openfirmware vs. FreeBSD conflict that makes booting unreliable for standard FreeBSD builds.) The details that are not driven by PowerMac G5 specifics look like: 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 311147) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) @@ -2336,6 +2336,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 Index: /usr/src/lib/csu/powerpc64/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/lib/csu/powerpc64/Makefile (revision 311147) +++ /usr/src/lib/csu/powerpc64/Makefile (working copy) @@ -5,19 +5,20 @@ SRCS=3D crt1.c crti.S crtn.S OBJS=3D ${SRCS:N*.h:R:S/$/.o/g} OBJS+=3D Scrt1.o gcrt1.o +.include +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -I${.CURDIR}/../common \ -I${.CURDIR}/../../libc/include \ -mlongcall +.else +CFLAGS+=3D -I${.CURDIR}/../common \ + -I${.CURDIR}/../../libc/include +.endif # XXX: See the log for r232932 as to why the above -mlongcall is needed. = Since # clang doesn't support -mlongcall, and testing shows a clang linked = with a # clang-built csu segfaults, this must currently be compiled with gcc. = Once # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. -.include -.if ${COMPILER_TYPE} !=3D "gcc" -CC:=3D gcc -COMPILER_TYPE:=3D gcc -.endif FILES=3D ${OBJS} FILESMODE=3D ${LIBMODE} Index: /usr/src/sys/boot/ofw/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/ofw/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/powerpc/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) @@ -2,6 +2,7 @@ .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/kboot/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/boot/powerpc/kboot/Makefile (revision 311147) +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) @@ -68,8 +68,6 @@ LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a .endif -CFLAGS+=3D -mcpu=3Dpowerpc64 - # Always add MI sources .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern .include "${.CURDIR}/../../common/Makefile.inc" @@ -85,9 +83,6 @@ LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc -# 64-bit bridge extensions -CFLAGS+=3D -Wa,-mppc64bridge - # Pull in common loader code #.PATH: ${.CURDIR}/../../ofw/common #.include "${.CURDIR}/../../ofw/common/Makefile.inc" Index: /usr/src/sys/boot/uboot/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/uboot/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/Makefile.powerpc (revision 311147) +++ /usr/src/sys/conf/Makefile.powerpc (working copy) @@ -39,7 +39,11 @@ # Force __SPE__, since the builtin will be removed later with -mno-spe CFLAGS+=3D -mabi=3Dspe -D__SPE__ .endif +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif # Build position-independent kernel CFLAGS+=3D -fPIC Index: /usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kern.mk (revision 311147) +++ /usr/src/sys/conf/kern.mk (working copy) @@ -162,7 +162,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kmod.mk (revision 311147) +++ /usr/src/sys/conf/kmod.mk (working copy) @@ -147,8 +147,12 @@ .endif .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls 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 311147) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,16 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS + .if ${MACHINE_ARCH} =3D=3D "powerpc64" +.include +.if ${COMPILER_TYPE} =3D=3D "gcc" +# gcc421 requires the -mminimal-toc . +# But clang 3.9.1 disallows it and does not need it. +# more modern gcc's allow it. CFLAGS+=3D-mminimal-toc .endif +.endif .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 Index: /usr/src/sys/powerpc/aim/trap_subr32.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/aim/trap_subr32.S (revision 311147) +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) @@ -406,7 +406,7 @@ mtctr %r1 /* load counter */ im1: lwzu %r1, 8(%r2) /* get next pte */ - cmp 0, %r1, %r3 /* see if found pte */ + cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, im1 /* dec count br if cmp ne and if * count not zero */ bne instr_sec_hash /* if not found set up second = hash Index: /usr/src/sys/powerpc/include/asm.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/include/asm.h (revision 311147) +++ /usr/src/sys/powerpc/include/asm.h (working copy) @@ -89,10 +89,11 @@ name: #ifdef __powerpc64__ -#define TOC_REF(name) __CONCAT(.L,name) +#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name) +#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc #define TOC_ENTRY(name) \ .section ".toc","aw"; \ - TOC_REF(name): \ + TOC_NAME_FOR_REF(name): \ .tc name[TC],name #endif =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 6:41 AM, Roman Divacky wrote: Mark, Would you be interested in trying lld? It has some support for = ppc/ppc64, which is probably quite incomplete but it would be nice to know what exactly = is missing. We also have some people (emaste@, davide@) that have non-trivial lld = knowledge so perhaps progress can be achieved on this side easily? Roman On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: > [I forgot to indicate that I still can not use the system bootstrapped > ld command and so there is a reason that I used = devel/powerpc64-binutils.] >=20 > On 2017-Jan-8, at 2:24 AM, Mark Millard = wrote: >=20 >> On 2017-Jan-8, at 1:03 AM, Roman Divacky = wrote: >>=20 >>> I think we should add the @toc notations to all the places where = it's needed. >>> Can you submit such a patch (perhaps with the one for adding 0 to = the cmp >>> instruction) so they can be committed to FreeBSD repo? >>=20 >> In order to test I added @toc to each of the 10 instructions instead >> of adjusting the macros so that instructions would automatically >> get the notation but other (what are now) TOC_REF(...) usage would >> not that should not. >>=20 >> I suspect Nathan and Justin might prefer a more automatic >> alternative so that TOC_REF(...) in an instruction would >> be sufficient without an explicit @toc in the instruction. >>=20 >> I'll see about switching to such code before providing a >> patch. I'd include the "0, " update to the cmp instruction. >>=20 >> But adding @toc's in those instructions (with prior workarounds >> as well) did allow me to build a bootable system based on using >> devel/powerpc64-binutils and clang 3.9.1 for both buildworld >> and buildkernel --still using clang's internal assembler. >>=20 >> One issue is that clang does not support (or need) the >> -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 >> requires it. For sys/modules/zfs/Makefile my source >> currently does not support gcc 4.2.1 without editing. >> As I remember devel/powerpc64-gcc >> (devel/powerpc64-xtoolchain-gcc) does not require the >> -mminimal-toc either. But devel/powerpc64-gcc does >> allow -mminimal-toc so it can be a clang vs. gcc based >> choice. >>=20 >> I might also deal with that before providing patches. >>=20 >> Note: -mlongcall was also not needed nor used for clang. >> (Still used for gcc.) >>=20 >> sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 >> and -Wa,-mppc64bridge that I eliminated (they messed up >> 32-bit powerpc builds) but I've no way to test kboot that >> I know of. This patch might be rejected. >>=20 >> Remember that I got this far in part by using your partial >> e500-instructions patch. I can provide my variant that >> is a diff with -r311147 instead of an older place in the >> history. But it would be incomplete coverage of those 2 >> instructions in clang. >>=20 >> Also I build with a workaround for PowerMac G5 boot >> reliability since OpenFirmware and FreeBSD interact >> badly at times on PowerMac G5's. This I would not >> provide as it is PowerMac G5 specific. >>=20 >>> If gnu as warns and llvm assembler does the wrong thing without @toc = and both >>> do the correct thing with @toc I think it's an obvious decision. >>=20 >> My choice would be to supply the @toc notation in some way, >> not necessarily the form I used for the initial test. >>=20 >>> Also, with all these changes. Does clang compiled kernel boot? >>=20 >> The PowerMac G5 so-called "Quad Core" that I currently have access >> to is now running from buildworld and buildkernel based on >> devel/powerpc64-binutils and clang 3.9.1 : >>=20 >> Copyright (c) 1992-2017 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 >> = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc >> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) >> . . . >>=20 >> # uname -apKU >> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat = Jan 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 >>=20 >> I've built about a dozen ports on it after booting but I've not >> done a self-hosted buildworld buildkernel yet. >>=20 >> [Note: Anything dependent on throwing C++ exceptions in >> code generated by clang++ 3.9.1 is broken.] >=20 > I should have been explicit: >=20 > I still can not use the system bootstrapped ld command > and such binutils for buildkernel and so there is a > reason that I used devel/powerpc64-binutils instead. >=20 > Thus even with my patches clang 3.9.1 would not be ready > for general use or for a default way of building. I > have to have a tailored SRC_ENV_CONF file or the like > still --and a port built and installed. >=20 > [On a powerpc64 system devel/binutils could be used.] >=20 > There is also the issue with throwing C++ exceptions > in code when clang 3.9.1 was the code generator used. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: >> [Top post about FreeBSD bugzilla 215819 and llvm bugzilla >> 31574 submittals for the issue involved.] >>=20 >> My guess is that FreeBSD will view this as a kernel >> source code issue and not as a toolchain issue. But >> it is only a guess on my part. >>=20 >>=20 >> I have submitted llvm bugzilla 31574 for this issue. It >> includes example .S file content that shows the "problem" >> in the generated .o file (form FreeBSD's view point). >> (I've no clue how llvm views its criteria relative to this >> mismatch with gcc/binutils.) >>=20 >> Because FreeBSD source code changes (being explicit about >> @toc) avoid the distinction between clang and gcc/binutils >> I've not added 31574 to the Depends on list for llvm 25780 >> (the FreeBSD system compiler issues META entry in llvm). >>=20 >> Someone with official status for FreeBSD could add 31574 to >> llvm's 25780 if FreeBSD wants to push llvm to match >> gcc/binutils for "@toc notation missing". >>=20 >> Otherwise this is a kernel source code issue (as I would >> guess) and not a toolchain issue. >>=20 >> Ed Maste or someone like that likely would make the final >> decision. >>=20 >>=20 >> I've added to FreeBSD Bugzilla 215819 the new information, >> including the simple example .S file content that shows the >> problem in the generated .o file. (Comments #3 and #4 >> have the new material.) >>=20 >> My guess is that FreeBSD Bugzilla 215819 should no longer >> be assigned to freebsd-toolchain@FreeBSD.org . Instead it >> would be a powerpc64 kernel source code issue if I'm right. >>=20 >> Ed Maste or someone like that likely would make this final >> decision as well. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2017-Jan-7, at 3:12 PM, Mark Millard = wrote: >>=20 >>> [I've supplied a list of places that adding @toc notation should >>> make clang 3.9.1 targeting powerpc64 do the right thing for >>> this issue.] >>>=20 >>> On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >>>=20 >>>> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>>>=20 >>>>> That's a great progress. Can you produce minimal self contained = test case that >>>>> exhibits this bug? And submit it to llvm bugzilla? >>>>>=20 >>>>> Also, clang3.9 defaults to using it's own internal asm, what = happens if you >>>>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>>>> this llvm assembly problem. Does it boot? >>>>>=20 >>>>> Thanks Mark, really great progress. >>>>>=20 >>>>> Roman >>>>=20 >>>> In attempting this I found how to control the behavior based on >>>> the assembler notation @toc being missing vs. being present. >>>>=20 >>>> If llvm should change is strongly tied to llvm's criteria for >>>> gcc compatibility relative to filling-in/defaulting omitted >>>> @toc's in the assembler notation. >>>>=20 >>>> FreeBSD has the option of always being explicit with @toc in order >>>> to avoid differences in handling of omitted notation. >>>>=20 >>>> So I've no clue if FreebSD wants to claim that a llvm change >>>> is a requirement for using clang as the powerpc64 system compiler. >>>>=20 >>>> [The issue of the distinction is submittable to llvm either way.] >>>>=20 >>>> Details. . . >>>>=20 >>>> For: >>>>=20 >>>> .section ".toc","aw" >>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>> . . . >>>> /* Set up the stack pointer */ >>>> ld %r1,tmpstk.L(%r2) >>>>=20 >>>> using devel/powerpc64-gcc gets: >>>>=20 >>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>>=20 >>>> = locore64_simplified.S >>>> locore64_simplified.S: Assembler messages: >>>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>>=20 >>>> and produces (with R_PPC64_TOC16_DS for .toc): >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>>>=20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>> By contrast clang is silent (cross compiler used): >>>>=20 >>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>>=20 >>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>=20 >>>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>>=20 >>>> But for: >>>>=20 >>>> .section ".toc","aw" >>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>> . . . >>>> /* Set up the stack pointer */ >>>> ld %r1,tmpstk.L@toc(%r2) >>>>=20 >>>> (note the @toc notation) both compilers agree and use >>>> R_PPC64_TOC16_DS for the .toc: >>>>=20 >>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>>=20 >>>> = locore64_simplified.S >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>>=20 >>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>>=20 >>>> I omitted "-f -gdwarf-2" to simplify things but with such >>>> clang complains about: >>>>=20 >>>> locore64_simplified.S:36:2: warning: DWARF2 only supports one = section per compilation unit >>>> .section ".toc","aw" >>>> ^ >>>> locore64_simplified.S:47:2: warning: DWARF2 only supports one = section per compilation unit >>>> .section ".opd","aw" >>>> ^ >>>>=20 >>>> (buildkernel gets such messages.) >>>>=20 >>>>=20 >>>> I expect I can simplify the .S code more than I have so far but >>>> I figured I'd report the discovery of the choice FreeBSD needs >>>> to make for powerpc64 for if llvm changes are to be required >>>> vs. not. >>>=20 >>> The following should be a list of the places that adding @toc usage >>> would fix some things for using clang 3.9.1 to target powerpc64: >>>=20 >>> # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more >>> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc = on symbol >>> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc = on symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc = on symbol >>>=20 >>> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report >>> on missing @toc 's. >>>=20 >>> But, of course, if some sections of code are conditionally compiled = and >>> excluded above they would not be listed. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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-ppc@freebsd.org Tue Jan 10 02:00:31 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4D8FCA4121 for ; Tue, 10 Jan 2017 02:00:31 +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 B48A81433 for ; Tue, 10 Jan 2017 02:00:31 +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 v0A20VUA014404 for ; Tue, 10 Jan 2017 02:00:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Tue, 10 Jan 2017 02:00:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hamiltcl@verizon.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 02:00:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #19 from Curtis Hamilton --- It's really a guess on my part, but I looks that somehow another library is being used by ld. Are you sure there is no default libstdc++.so in /usr/lib= ? It could be that the search order of RPATH is finding another library and using it. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Jan 10 09:12:24 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5AC5CA6321 for ; Tue, 10 Jan 2017 09:12:24 +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 946951A55 for ; Tue, 10 Jan 2017 09:12:24 +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 v0A9COs4035835 for ; Tue, 10 Jan 2017 09:12:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction Date: Tue, 10 Jan 2017 09:12:24 +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: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ppc@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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:12:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215681 --- Comment #4 from Mark Millard --- Created attachment 178692 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178692&action= =3Dedit Avoid omitting the supposedly optional operand to cmp instruction clang 3.9.1 targeting powerpc (32-bit) reports a missing operand error for cmp with 3 operands, requiring the supposedly optional operand. The kernel has one example of the rejected notation: change it to supply all 4 operands --like the other cmp usage in the same file. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Tue Jan 10 10:04:36 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57A2DCA8B42 for ; Tue, 10 Jan 2017 10:04: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 463651654 for ; Tue, 10 Jan 2017 10:04: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 v0AA4aVv062326 for ; Tue, 10 Jan 2017 10:04:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM) Date: Tue, 10 Jan 2017 10:04:36 +0000 X-Bugzilla-Reason: CC 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: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@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-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:04:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205458 --- Comment #9 from Mark Millard --- (In reply to Nathan Whitehorn from comment #4) There seems to have been no activity for this since comment #6 reported the patch failed on a PowerMac 7,3 . So it has been sitting in the In Progress state for about 4 months (2016-Sep-13 to 2017-Jan-10) as I write this. Comment 6 basically reports that some of the special purpose register(s) do need to be saved and restored, just not all of them. Nathan's patch had completely disabled ofw_sprg_prepare and its matching restore for __powerpc64__ . Unfortunately for now I've only access to a PowerMac 11,2 (a so-called "Quad Core" PowerMac G5) so for now I could only test the context that Nathan found to be working for his 2016-Sep patch. I should eventually have access to a PowerMac 7,2 form of G5 again. Still I wonder about 205458 showing "In Progress" for long periods. It might get lost with folks thinking it is being worked on when other higher priority things may have displaced its activity for a long time (even starting from now). However, closing the defect seems wrong as well. Going back to new would seem better. But as it shows to me such is not an option: closed is the only alternative to In Progress. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Jan 10 10:30:37 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79768CA98A7 for ; Tue, 10 Jan 2017 10:30:37 +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 681951E1E for ; Tue, 10 Jan 2017 10:30:37 +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 v0AAUbSJ016582 for ; Tue, 10 Jan 2017 10:30:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 205455] 11.0-CURRENT sys/boot/ofw/Makfile.inc , powerpc/Makefile , and uboot/Makefile.inc LDFLAGS patches for powerpc64: use -Wl, (enabled using xtoolchain based builds) Date: Tue, 10 Jan 2017 10:30:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-BETA1 X-Bugzilla-Keywords: patch 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-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:30:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205455 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|11.0-CURRENT |11.0-CURRENT |sys/boot/ofw/Makfile.inc , |sys/boot/ofw/Makfile.inc , |powerpc/Makefile , and |powerpc/Makefile , and |uboot/Makefile.inc LDFLAGS |uboot/Makefile.inc LDFLAGS |patches for powerpc64: use |patches for powerpc64: use |-Wl, |-Wl, (enabled using | |xtoolchain based builds) Component|misc |kern --- Comment #2 from Mark Millard --- Looks like I misclassified this as misc instead of kernel back on 2015-Dec-20. So set it to kernel now. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Jan 10 21:19:14 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6B8FCAA5CF for ; Tue, 10 Jan 2017 21:19:14 +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 72DDD1516 for ; Tue, 10 Jan 2017 21:19:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21549 invoked from network); 10 Jan 2017 21:19:07 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Jan 2017 21:19:07 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Tue, 10 Jan 2017 16:19:07 -0500 (EST) Received: (qmail 7889 invoked from network); 10 Jan 2017 21:19:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Jan 2017 21:19:07 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3F2AAEC91B5; Tue, 10 Jan 2017 13:19:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <964800DA-213A-4855-A5E7-8C62823E55D5@dsl-only.net> Date: Tue, 10 Jan 2017 13:19:05 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> <20170108144133.GA19529@vlakno.cz> <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> <964800DA-213A-4855-A5E7-8C62823E55D5@dsl-only.net> To: Roman Divacky , Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:19:14 -0000 I have added the patches to my various historical submittals and submitted some I'd never made submittals for. For the sys/modules/zfs/Makefile I eliminated the extra blank line that was added in what I showed earlier for the patches. Some of the patches are tied to allowing all 3 types of buidlworld buildkernel contexts in Makefile* 's for one or both of powerpc64 and powerpc: 0) system gcc 4.2.1 and (bootstrapped) system binutils (not libc++ based) 1) devel/powerpc64-xtoolchain-gcc devel/powerpc64-gcc = devel/powerpc64-binutils (libc++ based, no lib32) 2) system clang and devel/powerpc64-binutils or (bootstrapped) system = binutils (One(?) driven by 3.8.0 that would not be needed for 3.9.1) (libc++ based) Some contexts require options that the others do not. Some contexts require options that others do not allow and do not need. Some I added note to about potentially using CFLAGS.gcc+=3D and CFLAGS.clang+=3D instead of conditional logic if the contexts allow such to be effective. The bugzilla numbers (if I found them all): 205455 206303 214904 (the patch allowed building but is not a complete clang/llvm = update) 215107 215681 215819 215947 215948 Generally this list excludes things for which WERROR=3D allows the buildkernel attempts to complete and things related to restrictions like avoiding lib32 for devel/powerpc64-gcc based builds. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 9:34 PM, Mark Millard wrote: I'll note that: Bug 214855 - head -r309179 TARGET_ARCH=3Dpowerpc64 clang 3.9.0 based = cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 = [FreeBSD] 2007-07-03 internal error means that I can not use the bootstrap binutils to do buildworld for = powerpc64. I've confirmed that it still happens in -r311147 . So to span both buildkernel and buildworld does require = devel/powerpc64-binutils or the like for TARGET_ARCH=3Dpowerpc64 . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 4:40 PM, Mark Millard wrote: [I've not tried lldb yet but I have good news. . .] Well it turns out I was wrong: after the @toc changes (now in the TOC_REF(...) macro instead of per instruction) I can boot a kernel built using the bootstrap system binutils and clang as well. devel/powerpc64-binutils or the like is not required. It looks like bugzilla 215821 is wrong/redundant and 215819 actually covers the issue. I will likely close 215821 after I've played around some more. I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc = 4.2.1 as I have things. clang 3.9.1 based builds do not handle throwing C++ exceptions. lib32 does not work for devel/powerpc64-gcc based builds. As stands I have head -r311147 with: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c (Not relevant) M /usr/src/sys/ddb/db_script.c (Not relevant) M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/aim/trap_subr32.S M /usr/src/sys/powerpc/include/asm.h M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant) The various KERNCONF's include standard ones then adjust things. They are not otherwise relevant. Notes on the differences ("M" lines): [I do not have a context to test powerpc's kboot or uboot for powerpc or powerpc64: only PowerMacs. Those Makefile changes were based on avoiding build errors that occurred before the change (long ago). I've not gone back through the armv6(/v7) and arm64 builds recently but historically they have worked on the rpi2, bpim3, and pine64 with the boot/uboot/Makefile.inc change in place.] llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s incomplete patch for the e500 instructions. It was sufficient to let me continue. The various Makefile*'s and *.mk's deal with: -mlongcall (gcc) vs. not (clang) -m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new) -mcpu=3Dpowerpc64 and -Wa,-mppc64bridge in a Makefile (kboot) that TARGET_ARCH=3Dpowerpc tried to build and failed: delete the usage of these options. (No test validation of built kboot result!) -Wa,many for gcc vs. no-such for clang sys/conf/kern.mk deals with: -mllvm -disable-ppc-float-in-variadic=3Dtrue (older clang) vs. -msoft-float (newer clang) sys/modules/zfs/Makefile deals with: -mminimial-toc (gcc) vs. no-such (clang) sys/ddb/db_main.c and sys/ddb/db_script.c : These would not be included. (They set up to execute a built-in default script so I get information for early boot issues from before ddb takes input.) sys/powerpc/aim/trap_subr32.S deals with: Have a cmp instruction be explicit by adding a "0, ". (This is a TARGET_ARCH=3Dpowerpc issue, not a TARGET_ARCH=3Dpowerpc64 issue.) sys/powerpc/include/asm.h deals with: Have TOC_REF(...) also include @toc in the notation that results. Have a TOC_NAME_FOR_REF(...) that only adds the .L to the name passed in and use it where appropriate. sys/powerpc/ofw/ofw_machdep.c : This would not be included. (It is a PowerMac G5 specific workaround for a openfirmware vs. FreeBSD conflict that makes booting unreliable for standard FreeBSD builds.) The details that are not driven by PowerMac G5 specifics look like: 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 311147) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) @@ -2336,6 +2336,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 Index: /usr/src/lib/csu/powerpc64/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/lib/csu/powerpc64/Makefile (revision 311147) +++ /usr/src/lib/csu/powerpc64/Makefile (working copy) @@ -5,19 +5,20 @@ SRCS=3D crt1.c crti.S crtn.S OBJS=3D ${SRCS:N*.h:R:S/$/.o/g} OBJS+=3D Scrt1.o gcrt1.o +.include +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -I${.CURDIR}/../common \ -I${.CURDIR}/../../libc/include \ -mlongcall +.else +CFLAGS+=3D -I${.CURDIR}/../common \ + -I${.CURDIR}/../../libc/include +.endif # XXX: See the log for r232932 as to why the above -mlongcall is needed. = Since # clang doesn't support -mlongcall, and testing shows a clang linked = with a # clang-built csu segfaults, this must currently be compiled with gcc. = Once # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. -.include -.if ${COMPILER_TYPE} !=3D "gcc" -CC:=3D gcc -COMPILER_TYPE:=3D gcc -.endif FILES=3D ${OBJS} FILESMODE=3D ${LIBMODE} Index: /usr/src/sys/boot/ofw/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/ofw/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/powerpc/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) @@ -2,6 +2,7 @@ .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/kboot/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/boot/powerpc/kboot/Makefile (revision 311147) +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) @@ -68,8 +68,6 @@ LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a .endif -CFLAGS+=3D -mcpu=3Dpowerpc64 - # Always add MI sources .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern .include "${.CURDIR}/../../common/Makefile.inc" @@ -85,9 +83,6 @@ LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc -# 64-bit bridge extensions -CFLAGS+=3D -Wa,-mppc64bridge - # Pull in common loader code #.PATH: ${.CURDIR}/../../ofw/common #.include "${.CURDIR}/../../ofw/common/Makefile.inc" Index: /usr/src/sys/boot/uboot/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/uboot/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} =3D=3D "powerpc64" CFLAGS+=3D -m32 -mcpu=3Dpowerpc -LDFLAGS+=3D -m elf32ppc_fbsd +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/Makefile.powerpc (revision 311147) +++ /usr/src/sys/conf/Makefile.powerpc (working copy) @@ -39,7 +39,11 @@ # Force __SPE__, since the builtin will be removed later with -mno-spe CFLAGS+=3D -mabi=3Dspe -D__SPE__ .endif +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif # Build position-independent kernel CFLAGS+=3D -fPIC Index: /usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kern.mk (revision 311147) +++ /usr/src/sys/conf/kern.mk (working copy) @@ -162,7 +162,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kmod.mk (revision 311147) +++ /usr/src/sys/conf/kmod.mk (working copy) @@ -147,8 +147,12 @@ .endif .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls 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 311147) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,16 @@ CFLAGS+=3D-I${SUNW}/common CFLAGS+=3D-DBUILDING_ZFS + .if ${MACHINE_ARCH} =3D=3D "powerpc64" +.include +.if ${COMPILER_TYPE} =3D=3D "gcc" +# gcc421 requires the -mminimal-toc . +# But clang 3.9.1 disallows it and does not need it. +# more modern gcc's allow it. CFLAGS+=3D-mminimal-toc .endif +.endif .ifdef ZFS_DEBUG CFLAGS+=3D-DDEBUG=3D1 Index: /usr/src/sys/powerpc/aim/trap_subr32.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/aim/trap_subr32.S (revision 311147) +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) @@ -406,7 +406,7 @@ mtctr %r1 /* load counter */ im1: lwzu %r1, 8(%r2) /* get next pte */ - cmp 0, %r1, %r3 /* see if found pte */ + cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, im1 /* dec count br if cmp ne and if * count not zero */ bne instr_sec_hash /* if not found set up second = hash Index: /usr/src/sys/powerpc/include/asm.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/include/asm.h (revision 311147) +++ /usr/src/sys/powerpc/include/asm.h (working copy) @@ -89,10 +89,11 @@ name: #ifdef __powerpc64__ -#define TOC_REF(name) __CONCAT(.L,name) +#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name) +#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc #define TOC_ENTRY(name) \ .section ".toc","aw"; \ - TOC_REF(name): \ + TOC_NAME_FOR_REF(name): \ .tc name[TC],name #endif =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 6:41 AM, Roman Divacky wrote: Mark, Would you be interested in trying lld? It has some support for = ppc/ppc64, which is probably quite incomplete but it would be nice to know what exactly = is missing. We also have some people (emaste@, davide@) that have non-trivial lld = knowledge so perhaps progress can be achieved on this side easily? Roman On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: > [I forgot to indicate that I still can not use the system bootstrapped > ld command and so there is a reason that I used = devel/powerpc64-binutils.] >=20 > On 2017-Jan-8, at 2:24 AM, Mark Millard = wrote: >=20 >> On 2017-Jan-8, at 1:03 AM, Roman Divacky = wrote: >>=20 >>> I think we should add the @toc notations to all the places where = it's needed. >>> Can you submit such a patch (perhaps with the one for adding 0 to = the cmp >>> instruction) so they can be committed to FreeBSD repo? >>=20 >> In order to test I added @toc to each of the 10 instructions instead >> of adjusting the macros so that instructions would automatically >> get the notation but other (what are now) TOC_REF(...) usage would >> not that should not. >>=20 >> I suspect Nathan and Justin might prefer a more automatic >> alternative so that TOC_REF(...) in an instruction would >> be sufficient without an explicit @toc in the instruction. >>=20 >> I'll see about switching to such code before providing a >> patch. I'd include the "0, " update to the cmp instruction. >>=20 >> But adding @toc's in those instructions (with prior workarounds >> as well) did allow me to build a bootable system based on using >> devel/powerpc64-binutils and clang 3.9.1 for both buildworld >> and buildkernel --still using clang's internal assembler. >>=20 >> One issue is that clang does not support (or need) the >> -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 >> requires it. For sys/modules/zfs/Makefile my source >> currently does not support gcc 4.2.1 without editing. >> As I remember devel/powerpc64-gcc >> (devel/powerpc64-xtoolchain-gcc) does not require the >> -mminimal-toc either. But devel/powerpc64-gcc does >> allow -mminimal-toc so it can be a clang vs. gcc based >> choice. >>=20 >> I might also deal with that before providing patches. >>=20 >> Note: -mlongcall was also not needed nor used for clang. >> (Still used for gcc.) >>=20 >> sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 >> and -Wa,-mppc64bridge that I eliminated (they messed up >> 32-bit powerpc builds) but I've no way to test kboot that >> I know of. This patch might be rejected. >>=20 >> Remember that I got this far in part by using your partial >> e500-instructions patch. I can provide my variant that >> is a diff with -r311147 instead of an older place in the >> history. But it would be incomplete coverage of those 2 >> instructions in clang. >>=20 >> Also I build with a workaround for PowerMac G5 boot >> reliability since OpenFirmware and FreeBSD interact >> badly at times on PowerMac G5's. This I would not >> provide as it is PowerMac G5 specific. >>=20 >>> If gnu as warns and llvm assembler does the wrong thing without @toc = and both >>> do the correct thing with @toc I think it's an obvious decision. >>=20 >> My choice would be to supply the @toc notation in some way, >> not necessarily the form I used for the initial test. >>=20 >>> Also, with all these changes. Does clang compiled kernel boot? >>=20 >> The PowerMac G5 so-called "Quad Core" that I currently have access >> to is now running from buildworld and buildkernel based on >> devel/powerpc64-binutils and clang 3.9.1 : >>=20 >> Copyright (c) 1992-2017 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 >> = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc >> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) >> . . . >>=20 >> # uname -apKU >> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat = Jan 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 >>=20 >> I've built about a dozen ports on it after booting but I've not >> done a self-hosted buildworld buildkernel yet. >>=20 >> [Note: Anything dependent on throwing C++ exceptions in >> code generated by clang++ 3.9.1 is broken.] >=20 > I should have been explicit: >=20 > I still can not use the system bootstrapped ld command > and such binutils for buildkernel and so there is a > reason that I used devel/powerpc64-binutils instead. >=20 > Thus even with my patches clang 3.9.1 would not be ready > for general use or for a default way of building. I > have to have a tailored SRC_ENV_CONF file or the like > still --and a port built and installed. >=20 > [On a powerpc64 system devel/binutils could be used.] >=20 > There is also the issue with throwing C++ exceptions > in code when clang 3.9.1 was the code generator used. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: >> [Top post about FreeBSD bugzilla 215819 and llvm bugzilla >> 31574 submittals for the issue involved.] >>=20 >> My guess is that FreeBSD will view this as a kernel >> source code issue and not as a toolchain issue. But >> it is only a guess on my part. >>=20 >>=20 >> I have submitted llvm bugzilla 31574 for this issue. It >> includes example .S file content that shows the "problem" >> in the generated .o file (form FreeBSD's view point). >> (I've no clue how llvm views its criteria relative to this >> mismatch with gcc/binutils.) >>=20 >> Because FreeBSD source code changes (being explicit about >> @toc) avoid the distinction between clang and gcc/binutils >> I've not added 31574 to the Depends on list for llvm 25780 >> (the FreeBSD system compiler issues META entry in llvm). >>=20 >> Someone with official status for FreeBSD could add 31574 to >> llvm's 25780 if FreeBSD wants to push llvm to match >> gcc/binutils for "@toc notation missing". >>=20 >> Otherwise this is a kernel source code issue (as I would >> guess) and not a toolchain issue. >>=20 >> Ed Maste or someone like that likely would make the final >> decision. >>=20 >>=20 >> I've added to FreeBSD Bugzilla 215819 the new information, >> including the simple example .S file content that shows the >> problem in the generated .o file. (Comments #3 and #4 >> have the new material.) >>=20 >> My guess is that FreeBSD Bugzilla 215819 should no longer >> be assigned to freebsd-toolchain@FreeBSD.org . Instead it >> would be a powerpc64 kernel source code issue if I'm right. >>=20 >> Ed Maste or someone like that likely would make this final >> decision as well. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2017-Jan-7, at 3:12 PM, Mark Millard = wrote: >>=20 >>> [I've supplied a list of places that adding @toc notation should >>> make clang 3.9.1 targeting powerpc64 do the right thing for >>> this issue.] >>>=20 >>> On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >>>=20 >>>> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>>>=20 >>>>> That's a great progress. Can you produce minimal self contained = test case that >>>>> exhibits this bug? And submit it to llvm bugzilla? >>>>>=20 >>>>> Also, clang3.9 defaults to using it's own internal asm, what = happens if you >>>>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>>>> this llvm assembly problem. Does it boot? >>>>>=20 >>>>> Thanks Mark, really great progress. >>>>>=20 >>>>> Roman >>>>=20 >>>> In attempting this I found how to control the behavior based on >>>> the assembler notation @toc being missing vs. being present. >>>>=20 >>>> If llvm should change is strongly tied to llvm's criteria for >>>> gcc compatibility relative to filling-in/defaulting omitted >>>> @toc's in the assembler notation. >>>>=20 >>>> FreeBSD has the option of always being explicit with @toc in order >>>> to avoid differences in handling of omitted notation. >>>>=20 >>>> So I've no clue if FreebSD wants to claim that a llvm change >>>> is a requirement for using clang as the powerpc64 system compiler. >>>>=20 >>>> [The issue of the distinction is submittable to llvm either way.] >>>>=20 >>>> Details. . . >>>>=20 >>>> For: >>>>=20 >>>> .section ".toc","aw" >>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>> . . . >>>> /* Set up the stack pointer */ >>>> ld %r1,tmpstk.L(%r2) >>>>=20 >>>> using devel/powerpc64-gcc gets: >>>>=20 >>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>>=20 >>>> = locore64_simplified.S >>>> locore64_simplified.S: Assembler messages: >>>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>>=20 >>>> and produces (with R_PPC64_TOC16_DS for .toc): >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o >>>>=20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>> By contrast clang is silent (cross compiler used): >>>>=20 >>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>>=20 >>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>=20 >>>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>>=20 >>>> But for: >>>>=20 >>>> .section ".toc","aw" >>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>> . . . >>>> /* Set up the stack pointer */ >>>> ld %r1,tmpstk.L@toc(%r2) >>>>=20 >>>> (note the @toc notation) both compilers agree and use >>>> R_PPC64_TOC16_DS for the .toc: >>>>=20 >>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ = = =20 >=20 >>=20 >>>=20 >>>> = locore64_simplified.S >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ = =20 >=20 >>=20 >>>=20 >>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>=20 >>>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o = | more = = =20 >>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>=20 >>>> RELOCATION RECORDS FOR [.text]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.toc]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>=20 >>>>=20 >>>> RELOCATION RECORDS FOR [.opd]: >>>> OFFSET TYPE VALUE=20 >>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>=20 >>>>=20 >>>>=20 >>>> I omitted "-f -gdwarf-2" to simplify things but with such >>>> clang complains about: >>>>=20 >>>> locore64_simplified.S:36:2: warning: DWARF2 only supports one = section per compilation unit >>>> .section ".toc","aw" >>>> ^ >>>> locore64_simplified.S:47:2: warning: DWARF2 only supports one = section per compilation unit >>>> .section ".opd","aw" >>>> ^ >>>>=20 >>>> (buildkernel gets such messages.) >>>>=20 >>>>=20 >>>> I expect I can simplify the .S code more than I have so far but >>>> I figured I'd report the discovery of the choice FreeBSD needs >>>> to make for powerpc64 for if llvm changes are to be required >>>> vs. not. >>>=20 >>> The following should be a list of the places that adding @toc usage >>> would fix some things for using clang 3.9.1 to target powerpc64: >>>=20 >>> # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more >>> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc = on symbol >>> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc = on symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol >>> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc = on symbol >>>=20 >>> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to = report >>> on missing @toc 's. >>>=20 >>> But, of course, if some sections of code are conditionally compiled = and >>> excluded above they would not be listed. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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-ppc@freebsd.org Wed Jan 11 02:26:19 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3556CAA731; Wed, 11 Jan 2017 02:26:19 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 928931A2E; Wed, 11 Jan 2017 02:26:19 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x243.google.com with SMTP id c20so14682489itb.0; Tue, 10 Jan 2017 18:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=1MFUXuqf8Tn2f0TL/uEXJxlKs8rHsDdv1Y0lH7B961U=; b=Mi1oljQVKUgy8wqnqc2FXkBsQMooDvruma56fBOUd8xOX5jQfQrs/C4VEVDt2DmfwG YdPsu+P/Hk6L1sKhy1gO4jTzjXN4+Ffdsq29zHHTwJsZvz8+PhXdeKTSOHH0g/iCu64o RJu5T0KwfPvz/hLMfobrfMp5h3IVkEjvD+PjRLXcZ0sLAhO4B5uWHuoQ/lTsnCBDcrkA d2PYlh8m+CTobJmfgP6pHpyvG0jDaWhXY6H5GKWlEkk4yE8juExgQaYE4RJpkOnYhUIy HZAFxnH4NF6l3ar/PDvoFHoeElXs9un379lE5RtBTCr29mLcGMq1ejkk+9XYCF46Ke8e 81BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=1MFUXuqf8Tn2f0TL/uEXJxlKs8rHsDdv1Y0lH7B961U=; b=RFObFz3D5LCzN+IfNSoqyidT8CCD2Nks14+w849rFcXU/QGRH7S11/qooWxdGBWRJg wLopY+kB0MfcNwYomz3PIuxHFYfw83dz7CT860Fi4IzQqRnv45w9b4coP1+WqDAcnoxL FMSWamJjXBv5iDK+7obAG8pSuj763m2Fjz0OoTKOzVJIaiYtNkxIEcRePSsRRvARstRU yGONeWh6JKJQODJUJXZEb5jOxQ+1nsPgovxjvxoLLVtVAqbQF2cQwxdthXFPmBNbeb/n ZJFrHxzbsk7k+9nE1QozBt6coPuV7RuBc0NUvpazwZosbdL9SjTxrNVIOCkfBjqaxsjj qeLg== X-Gm-Message-State: AIkVDXJleBs83cWZnjXBLqF4wbWdTfmdCgObwvskKfGgJ/f6XLT8+WdFCAJ/bsUYkbdaEg== X-Received: by 10.36.163.1 with SMTP id p1mr2955333ite.79.1484101577986; Tue, 10 Jan 2017 18:26:17 -0800 (PST) Received: from blackstar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id i2sm2339189ioe.34.2017.01.10.18.26.16 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Jan 2017 18:26:17 -0800 (PST) Cc: Roman Divacky , Ed Maste , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: <4B492B88-5545-40A2-B611-6D407A00F6C5@gmail.com> From: Justin Hibbits To: Mark Millard In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] Date: Tue, 10 Jan 2017 20:26:15 -0600 References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> <20170108144133.GA19529@vlakno.cz> <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> <964800DA-213A-4855-A5E7-8C62823E55D5@dsl-only.net> X-Mailer: Apple Mail (2.936) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:26:19 -0000 Hi Mark, Thanks for all the work you've put into getting FreeBSD/powerpc* building with clang, it's much appreciated. As time permits I'll be reviewing and marshalling your patches in. The fix for PR 215819 just went in (r311912), and will be MFC'd along with all the other patches after they're all in HEAD (I chose 2 weeks as a good ballpark frame). The others will go in as I regression test them. - Justin On Jan 10, 2017, at 3:19 PM, Mark Millard wrote: > I have added the patches to my various historical submittals > and submitted some I'd never made submittals for. > > For the sys/modules/zfs/Makefile I eliminated the extra blank line > that was added in what I showed earlier for the patches. > > Some of the patches are tied to allowing all 3 types of > buidlworld buildkernel contexts in Makefile* 's for > one or both of powerpc64 and powerpc: > > 0) system gcc 4.2.1 and (bootstrapped) system binutils > (not libc++ based) > > 1) devel/powerpc64-xtoolchain-gcc devel/powerpc64-gcc devel/ > powerpc64-binutils > (libc++ based, no lib32) > > 2) system clang and devel/powerpc64-binutils or (bootstrapped) > system binutils > (One(?) driven by 3.8.0 that would not be needed for 3.9.1) > (libc++ based) > > Some contexts require options that the others do not. > Some contexts require options that others do not allow and do not > need. > > Some I added note to about potentially using CFLAGS.gcc+= and > CFLAGS.clang+= instead of conditional logic if the contexts allow > such to be effective. > > The bugzilla numbers (if I found them all): > > 205455 > 206303 > 214904 (the patch allowed building but is not a complete clang/llvm > update) > 215107 > 215681 > 215819 > 215947 > 215948 > > Generally this list excludes things for which WERROR= allows the > buildkernel attempts to complete and things related to restrictions > like avoiding lib32 for devel/powerpc64-gcc based builds. > > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-8, at 9:34 PM, Mark Millard wrote: > > I'll note that: > > Bug 214855 - head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based > cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 > [FreeBSD] 2007-07-03 internal error > > means that I can not use the bootstrap binutils to do buildworld for > powerpc64. > I've confirmed that it still happens in -r311147 . > > So to span both buildkernel and buildworld does require devel/ > powerpc64-binutils > or the like for TARGET_ARCH=powerpc64 . > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-8, at 4:40 PM, Mark Millard > wrote: > > [I've not tried lldb yet but I have good news. . .] > > Well it turns out I was wrong: after the @toc changes (now in the > TOC_REF(...) macro instead of per instruction) I can boot a kernel > built > using the bootstrap system binutils and clang as well. > devel/powerpc64-binutils or the like is not required. > > It looks like bugzilla 215821 is wrong/redundant and 215819 actually > covers the issue. I will likely close 215821 after I've played around > some more. > > I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc > 4.2.1 > as I have things. clang 3.9.1 based builds do not handle throwing C++ > exceptions. lib32 does not work for devel/powerpc64-gcc based builds. > > > As stands I have head -r311147 with: > > # svnlite status /usr/src/ | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/BPIM3-DBG > ? /usr/src/sys/arm/conf/BPIM3-NODBG > ? /usr/src/sys/arm/conf/RPI2-DBG > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > M /usr/src/lib/csu/powerpc64/Makefile > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/ddb/db_main.c (Not relevant) > M /usr/src/sys/ddb/db_script.c (Not relevant) > M /usr/src/sys/modules/zfs/Makefile > M /usr/src/sys/powerpc/aim/trap_subr32.S > M /usr/src/sys/powerpc/include/asm.h > M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant) > > The various KERNCONF's include standard ones then adjust things. > They are not otherwise relevant. > > > Notes on the differences ("M" lines): > > [I do not have a context to test powerpc's kboot or uboot > for powerpc or powerpc64: only PowerMacs. Those Makefile > changes were based on avoiding build errors that occurred > before the change (long ago). I've not gone back through > the armv6(/v7) and arm64 builds recently but historically > they have worked on the rpi2, bpim3, and pine64 with the > boot/uboot/Makefile.inc change in place.] > > > llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s > incomplete patch for the e500 instructions. It was > sufficient to let me continue. > > > The various Makefile*'s and *.mk's deal with: > > -mlongcall (gcc) vs. not (clang) > > -m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new) > > -mcpu=powerpc64 and -Wa,-mppc64bridge in a Makefile > (kboot) that TARGET_ARCH=powerpc tried to build and > failed: delete the usage of these options. (No test > validation of built kboot result!) > > -Wa,many for gcc vs. no-such for clang > > > sys/conf/kern.mk deals with: > > -mllvm -disable-ppc-float-in-variadic=true (older clang) > vs. > -msoft-float (newer clang) > > > sys/modules/zfs/Makefile deals with: > > -mminimial-toc (gcc) vs. no-such (clang) > > > sys/ddb/db_main.c and sys/ddb/db_script.c : > > These would not be included. (They set up to execute > a built-in default script so I get information for > early boot issues from before ddb takes input.) > > > sys/powerpc/aim/trap_subr32.S deals with: > > Have a cmp instruction be explicit by adding a "0, ". > (This is a TARGET_ARCH=powerpc issue, not a > TARGET_ARCH=powerpc64 issue.) > > > sys/powerpc/include/asm.h deals with: > > Have TOC_REF(...) also include @toc in the notation > that results. Have a TOC_NAME_FOR_REF(...) that only > adds the .L to the name passed in and use it where > appropriate. > > > sys/powerpc/ofw/ofw_machdep.c : > > This would not be included. (It is a PowerMac G5 specific > workaround for a openfirmware vs. FreeBSD conflict that > makes booting unreliable for standard FreeBSD builds.) > > > > The details that are not driven by PowerMac G5 specifics > look like: > > Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > =================================================================== > --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > (revision 311147) > +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > (working copy) > @@ -2336,6 +2336,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 > Index: /usr/src/lib/csu/powerpc64/Makefile > =================================================================== > --- /usr/src/lib/csu/powerpc64/Makefile (revision 311147) > +++ /usr/src/lib/csu/powerpc64/Makefile (working copy) > @@ -5,19 +5,20 @@ > SRCS= crt1.c crti.S crtn.S > OBJS= ${SRCS:N*.h:R:S/$/.o/g} > OBJS+= Scrt1.o gcrt1.o > +.include > +.if ${COMPILER_TYPE} == "gcc" > CFLAGS+= -I${.CURDIR}/../common \ > -I${.CURDIR}/../../libc/include \ > -mlongcall > +.else > +CFLAGS+= -I${.CURDIR}/../common \ > + -I${.CURDIR}/../../libc/include > +.endif > > # XXX: See the log for r232932 as to why the above -mlongcall is > needed. Since > # clang doesn't support -mlongcall, and testing shows a clang linked > with a > # clang-built csu segfaults, this must currently be compiled with > gcc. Once > # clang supports -mlongcall, or we get a fixed ld, this can be > revisited. > -.include > -.if ${COMPILER_TYPE} != "gcc" > -CC:= gcc > -COMPILER_TYPE:= gcc > -.endif > > FILES= ${OBJS} > FILESMODE= ${LIBMODE} > Index: /usr/src/sys/boot/ofw/Makefile.inc > =================================================================== > --- /usr/src/sys/boot/ofw/Makefile.inc (revision 311147) > +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > > .if ${MACHINE_ARCH} == "powerpc64" > CFLAGS+= -m32 -mcpu=powerpc > -LDFLAGS+= -m elf32ppc_fbsd > +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd > .endif > > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/Makefile.inc > =================================================================== > --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 311147) > +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,6 +2,7 @@ > > .if ${MACHINE_ARCH} == "powerpc64" > CFLAGS+= -m32 -mcpu=powerpc > +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd > .endif > > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/kboot/Makefile > =================================================================== > --- /usr/src/sys/boot/powerpc/kboot/Makefile (revision 311147) > +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) > @@ -68,8 +68,6 @@ > LIBFICL= ${.OBJDIR}/../../ficl/libficl.a > .endif > > -CFLAGS+= -mcpu=powerpc64 > - > # Always add MI sources > .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern > .include "${.CURDIR}/../../common/Makefile.inc" > @@ -85,9 +83,6 @@ > > LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc > > -# 64-bit bridge extensions > -CFLAGS+= -Wa,-mppc64bridge > - > # Pull in common loader code > #.PATH: ${.CURDIR}/../../ofw/common > #.include "${.CURDIR}/../../ofw/common/Makefile.inc" > Index: /usr/src/sys/boot/uboot/Makefile.inc > =================================================================== > --- /usr/src/sys/boot/uboot/Makefile.inc (revision 311147) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > > .if ${MACHINE_ARCH} == "powerpc64" > CFLAGS+= -m32 -mcpu=powerpc > -LDFLAGS+= -m elf32ppc_fbsd > +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd > .endif > > .include "../Makefile.inc" > Index: /usr/src/sys/conf/Makefile.powerpc > =================================================================== > --- /usr/src/sys/conf/Makefile.powerpc (revision 311147) > +++ /usr/src/sys/conf/Makefile.powerpc (working copy) > @@ -39,7 +39,11 @@ > # Force __SPE__, since the builtin will be removed later with -mno-spe > CFLAGS+= -mabi=spe -D__SPE__ > .endif > +.if ${COMPILER_TYPE} == "gcc" > CFLAGS+= -msoft-float -Wa,-many > +.else > +CFLAGS+= -msoft-float > +.endif > > # Build position-independent kernel > CFLAGS+= -fPIC > Index: /usr/src/sys/conf/kern.mk > =================================================================== > --- /usr/src/sys/conf/kern.mk (revision 311147) > +++ /usr/src/sys/conf/kern.mk (working copy) > @@ -162,7 +162,11 @@ > # > .if ${MACHINE_CPUARCH} == "powerpc" > CFLAGS+= -mno-altivec > +.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 30800 > CFLAGS.clang+= -mllvm -disable-ppc-float-in-variadic=true > +.else > +CFLAGS.clang+= -msoft-float > +.endif > CFLAGS.gcc+= -msoft-float > INLINE_LIMIT?= 15000 > .endif > Index: /usr/src/sys/conf/kmod.mk > =================================================================== > --- /usr/src/sys/conf/kmod.mk (revision 311147) > +++ /usr/src/sys/conf/kmod.mk (working copy) > @@ -147,8 +147,12 @@ > .endif > > .if ${MACHINE_CPUARCH} == powerpc > +.if ${COMPILER_TYPE} == "gcc" > CFLAGS+= -mlongcall -fno-omit-frame-pointer > +.else > +CFLAGS+= -fno-omit-frame-pointer > .endif > +.endif > > .if ${MACHINE_CPUARCH} == mips > CFLAGS+= -G0 -fno-pic -mno-abicalls -mlong-calls > Index: /usr/src/sys/modules/zfs/Makefile > =================================================================== > --- /usr/src/sys/modules/zfs/Makefile (revision 311147) > +++ /usr/src/sys/modules/zfs/Makefile (working copy) > @@ -93,9 +93,16 @@ > CFLAGS+=-I${SUNW}/common > CFLAGS+=-DBUILDING_ZFS > > + > .if ${MACHINE_ARCH} == "powerpc64" > +.include > +.if ${COMPILER_TYPE} == "gcc" > +# gcc421 requires the -mminimal-toc . > +# But clang 3.9.1 disallows it and does not need it. > +# more modern gcc's allow it. > CFLAGS+=-mminimal-toc > .endif > +.endif > > .ifdef ZFS_DEBUG > CFLAGS+=-DDEBUG=1 > Index: /usr/src/sys/powerpc/aim/trap_subr32.S > =================================================================== > --- /usr/src/sys/powerpc/aim/trap_subr32.S (revision 311147) > +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) > @@ -406,7 +406,7 @@ > mtctr %r1 /* load counter */ > im1: > lwzu %r1, 8(%r2) /* get next pte */ > - cmp 0, %r1, %r3 /* see if found pte */ > + cmp 0, 0, %r1, %r3 /* see if found pte */ > bdnzf 2, im1 /* dec count br if cmp ne and if > * count not zero */ > bne instr_sec_hash /* if not found set up second hash > Index: /usr/src/sys/powerpc/include/asm.h > =================================================================== > --- /usr/src/sys/powerpc/include/asm.h (revision 311147) > +++ /usr/src/sys/powerpc/include/asm.h (working copy) > @@ -89,10 +89,11 @@ > name: > > #ifdef __powerpc64__ > -#define TOC_REF(name) __CONCAT(.L,name) > +#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name) > +#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc > #define TOC_ENTRY(name) \ > .section ".toc","aw"; \ > - TOC_REF(name): \ > + TOC_NAME_FOR_REF(name): \ > .tc name[TC],name > #endif > > > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-8, at 6:41 AM, Roman Divacky wrote: > > Mark, > > Would you be interested in trying lld? It has some support for ppc/ > ppc64, which > is probably quite incomplete but it would be nice to know what > exactly is > missing. > > We also have some people (emaste@, davide@) that have non-trivial > lld knowledge > so perhaps progress can be achieved on this side easily? > > Roman > > On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: >> [I forgot to indicate that I still can not use the system >> bootstrapped >> ld command and so there is a reason that I used devel/powerpc64- >> binutils.] >> >> On 2017-Jan-8, at 2:24 AM, Mark Millard >> wrote: >> >>> On 2017-Jan-8, at 1:03 AM, Roman Divacky >>> wrote: >>> >>>> I think we should add the @toc notations to all the places where >>>> it's needed. >>>> Can you submit such a patch (perhaps with the one for adding 0 to >>>> the cmp >>>> instruction) so they can be committed to FreeBSD repo? >>> >>> In order to test I added @toc to each of the 10 instructions instead >>> of adjusting the macros so that instructions would automatically >>> get the notation but other (what are now) TOC_REF(...) usage would >>> not that should not. >>> >>> I suspect Nathan and Justin might prefer a more automatic >>> alternative so that TOC_REF(...) in an instruction would >>> be sufficient without an explicit @toc in the instruction. >>> >>> I'll see about switching to such code before providing a >>> patch. I'd include the "0, " update to the cmp instruction. >>> >>> But adding @toc's in those instructions (with prior workarounds >>> as well) did allow me to build a bootable system based on using >>> devel/powerpc64-binutils and clang 3.9.1 for both buildworld >>> and buildkernel --still using clang's internal assembler. >>> >>> One issue is that clang does not support (or need) the >>> -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 >>> requires it. For sys/modules/zfs/Makefile my source >>> currently does not support gcc 4.2.1 without editing. >>> As I remember devel/powerpc64-gcc >>> (devel/powerpc64-xtoolchain-gcc) does not require the >>> -mminimal-toc either. But devel/powerpc64-gcc does >>> allow -mminimal-toc so it can be a clang vs. gcc based >>> choice. >>> >>> I might also deal with that before providing patches. >>> >>> Note: -mlongcall was also not needed nor used for clang. >>> (Still used for gcc.) >>> >>> sys/boot/powerpc/kboot/Makefile has a -mcpu=powerpc64 >>> and -Wa,-mppc64bridge that I eliminated (they messed up >>> 32-bit powerpc builds) but I've no way to test kboot that >>> I know of. This patch might be rejected. >>> >>> Remember that I got this far in part by using your partial >>> e500-instructions patch. I can provide my variant that >>> is a diff with -r311147 instead of an older place in the >>> history. But it would be incomplete coverage of those 2 >>> instructions in clang. >>> >>> Also I build with a workaround for PowerMac G5 boot >>> reliability since OpenFirmware and FreeBSD interact >>> badly at times on PowerMac G5's. This I would not >>> provide as it is PowerMac G5 specific. >>> >>>> If gnu as warns and llvm assembler does the wrong thing without >>>> @toc and both >>>> do the correct thing with @toc I think it's an obvious decision. >>> >>> My choice would be to supply the @toc notation in some way, >>> not necessarily the form I used for the initial test. >>> >>>> Also, with all these changes. Does clang compiled kernel boot? >>> >>> The PowerMac G5 so-called "Quad Core" that I currently have access >>> to is now running from buildworld and buildkernel based on >>> devel/powerpc64-binutils and clang 3.9.1 : >>> >>> Copyright (c) 1992-2017 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, >>> 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 >>> markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/ >>> powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc >>> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based >>> on LLVM 3.9.1) >>> . . . >>> >>> # uname -apKU >>> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat >>> Jan 7 16:55:01 PST 2017 markmi@FreeBSDx64:/usr/obj/ >>> powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/ >>> sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 1200019 >>> >>> I've built about a dozen ports on it after booting but I've not >>> done a self-hosted buildworld buildkernel yet. >>> >>> [Note: Anything dependent on throwing C++ exceptions in >>> code generated by clang++ 3.9.1 is broken.] >> >> I should have been explicit: >> >> I still can not use the system bootstrapped ld command >> and such binutils for buildkernel and so there is a >> reason that I used devel/powerpc64-binutils instead. >> >> Thus even with my patches clang 3.9.1 would not be ready >> for general use or for a default way of building. I >> have to have a tailored SRC_ENV_CONF file or the like >> still --and a port built and installed. >> >> [On a powerpc64 system devel/binutils could be used.] >> >> There is also the issue with throwing C++ exceptions >> in code when clang 3.9.1 was the code generator used. >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: >>> [Top post about FreeBSD bugzilla 215819 and llvm bugzilla >>> 31574 submittals for the issue involved.] >>> >>> My guess is that FreeBSD will view this as a kernel >>> source code issue and not as a toolchain issue. But >>> it is only a guess on my part. >>> >>> >>> I have submitted llvm bugzilla 31574 for this issue. It >>> includes example .S file content that shows the "problem" >>> in the generated .o file (form FreeBSD's view point). >>> (I've no clue how llvm views its criteria relative to this >>> mismatch with gcc/binutils.) >>> >>> Because FreeBSD source code changes (being explicit about >>> @toc) avoid the distinction between clang and gcc/binutils >>> I've not added 31574 to the Depends on list for llvm 25780 >>> (the FreeBSD system compiler issues META entry in llvm). >>> >>> Someone with official status for FreeBSD could add 31574 to >>> llvm's 25780 if FreeBSD wants to push llvm to match >>> gcc/binutils for "@toc notation missing". >>> >>> Otherwise this is a kernel source code issue (as I would >>> guess) and not a toolchain issue. >>> >>> Ed Maste or someone like that likely would make the final >>> decision. >>> >>> >>> I've added to FreeBSD Bugzilla 215819 the new information, >>> including the simple example .S file content that shows the >>> problem in the generated .o file. (Comments #3 and #4 >>> have the new material.) >>> >>> My guess is that FreeBSD Bugzilla 215819 should no longer >>> be assigned to freebsd-toolchain@FreeBSD.org . Instead it >>> would be a powerpc64 kernel source code issue if I'm right. >>> >>> Ed Maste or someone like that likely would make this final >>> decision as well. >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >>> On 2017-Jan-7, at 3:12 PM, Mark Millard >>> wrote: >>> >>>> [I've supplied a list of places that adding @toc notation should >>>> make clang 3.9.1 targeting powerpc64 do the right thing for >>>> this issue.] >>>> >>>> On 2017-Jan-7, at 2:07 PM, Mark Millard >>>> wrote: >>>> >>>>> On 2017-Jan-7, at 12:51 AM, Roman Divacky >>>> vlakno.cz> wrote: >>>>> >>>>>> That's a great progress. Can you produce minimal self contained >>>>>> test case that >>>>>> exhibits this bug? And submit it to llvm bugzilla? >>>>>> >>>>>> Also, clang3.9 defaults to using it's own internal asm, what >>>>>> happens if you >>>>>> add -no-integrated-as to CFLAGS and recompile the kernel? That >>>>>> should remove >>>>>> this llvm assembly problem. Does it boot? >>>>>> >>>>>> Thanks Mark, really great progress. >>>>>> >>>>>> Roman >>>>> >>>>> In attempting this I found how to control the behavior based on >>>>> the assembler notation @toc being missing vs. being present. >>>>> >>>>> If llvm should change is strongly tied to llvm's criteria for >>>>> gcc compatibility relative to filling-in/defaulting omitted >>>>> @toc's in the assembler notation. >>>>> >>>>> FreeBSD has the option of always being explicit with @toc in order >>>>> to avoid differences in handling of omitted notation. >>>>> >>>>> So I've no clue if FreebSD wants to claim that a llvm change >>>>> is a requirement for using clang as the powerpc64 system compiler. >>>>> >>>>> [The issue of the distinction is submittable to llvm either way.] >>>>> >>>>> Details. . . >>>>> >>>>> For: >>>>> >>>>> .section ".toc","aw" >>>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>>> . . . >>>>> /* Set up the stack pointer */ >>>>> ld %r1,tmpstk.L(%r2) >>>>> >>>>> using devel/powerpc64-gcc gets: >>>>> >>>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc >>>>> \ -c >>>>> >>>>> \ -x >>>>> assembler-with-cpp >>>>> \ -pipe >>>>> \ > >> >>> >>>> >>>>> locore64_simplified >>>>> .S >>>>> locore64_simplified.S: Assembler messages: >>>>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>>> >>>>> and produces (with R_PPC64_TOC16_DS for .toc): >>>>> >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r >>>>> locore64_simplified.o >>>>> >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>> >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>> >>>>> >>>>> By contrast clang is silent (cross compiler used): >>>>> >>>>> # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/ >>>>> tmp/usr/bin/cc >>>>> \ -target >>>>> powerpc64-unknown-freebsd12.0 >>>>> \ --sysroot >>>>> =/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/ >>>>> tmp >>>>> \ -B >>>>> /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/ >>>>> tmp/usr/bin \ > >> >>> >>>> >>>>> -c >>>>> >>>>> \ -x >>>>> assembler-with-cpp >>>>> \ -pipe >>>>> >>>>> \ locore64_simplified >>>>> .S >>>>> >>>>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>>> >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r >>>>> locore64_simplified.o | more >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>> >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>> >>>>> >>>>> >>>>> But for: >>>>> >>>>> .section ".toc","aw" >>>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>>> . . . >>>>> /* Set up the stack pointer */ >>>>> ld %r1,tmpstk.L@toc(%r2) >>>>> >>>>> (note the @toc notation) both compilers agree and use >>>>> R_PPC64_TOC16_DS for the .toc: >>>>> >>>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc >>>>> \ -c >>>>> >>>>> \ -x >>>>> assembler-with-cpp >>>>> \ -pipe >>>>> \ > >> >>> >>>> >>>>> locore64_simplified >>>>> .S >>>>> >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r >>>>> locore64_simplified.o | more >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>> >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>> >>>>> >>>>> # /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/ >>>>> tmp/usr/bin/cc >>>>> \ -target >>>>> powerpc64-unknown-freebsd12.0 >>>>> \ --sysroot >>>>> =/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/ >>>>> tmp >>>>> \ -B >>>>> /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/ >>>>> tmp/usr/bin \ > >> >>> >>>> >>>>> -c >>>>> >>>>> \ -x >>>>> assembler-with-cpp >>>>> \ -pipe >>>>> >>>>> \ locore64_simplified >>>>> .S >>>>> >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r >>>>> locore64_simplified.o | more >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>> >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>> >>>>> >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>> >>>>> >>>>> >>>>> I omitted "-f -gdwarf-2" to simplify things but with such >>>>> clang complains about: >>>>> >>>>> locore64_simplified.S:36:2: warning: DWARF2 only supports one >>>>> section per compilation unit >>>>> .section ".toc","aw" >>>>> ^ >>>>> locore64_simplified.S:47:2: warning: DWARF2 only supports one >>>>> section per compilation unit >>>>> .section ".opd","aw" >>>>> ^ >>>>> >>>>> (buildkernel gets such messages.) >>>>> >>>>> >>>>> I expect I can simplify the .S code more than I have so far but >>>>> I figured I'd report the discovery of the choice FreeBSD needs >>>>> to make for powerpc64 for if llvm changes are to be required >>>>> vs. not. >>>> >>>> The following should be a list of the places that adding @toc usage >>>> would fix some things for using clang 3.9.1 to target powerpc64: >>>> >>>> # grep "@toc[^b]" /root/sys_typescripts/ >>>> typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolchain_kernel >>>> -amd64-host-2017-01-03:23:48:41 | more >>>> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming >>>> @toc on symbol >>>> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming >>>> @toc on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc >>>> on symbol >>>> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming >>>> @toc on symbol >>>> >>>> devel/powerpc64-gcc and devel/powerpc64-binutils together happens >>>> to report >>>> on missing @toc 's. >>>> >>>> But, of course, if some sections of code are conditionally >>>> compiled and >>>> excluded above they would not be listed. >>>> >>>> === >>>> 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-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-ppc@freebsd.org Wed Jan 11 02:38:01 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44941CAACA4 for ; Wed, 11 Jan 2017 02:38:01 +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 3433F1EC8 for ; Wed, 11 Jan 2017 02:38:01 +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 v0B2c05T086303 for ; Wed, 11 Jan 2017 02:38:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 200020] [patch] editors/libreoffice: enable build on powerpc64 Date: Wed, 11 Jan 2017 02:38:00 +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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: office@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:38:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200020 --- Comment #20 from Justin Hibbits --- (In reply to Curtis Hamilton from comment #19) There is, of course, the system libstdc++.so in /usr/lib. Looking at the command line, it appears libreoffice explicitly adds "-Wl,-rpath-link,/lib:/usr/lib" to the link line, such that /usr/lib/libstd= c++ is likely found before /usr/local/lib/gcc49/libstdc++.so . This could end = up being just another minor patch to unxgcc.mk . --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed Jan 11 04:04:27 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77421CAA513 for ; Wed, 11 Jan 2017 04:04:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-11.reflexion.net [208.70.210.11]) (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 1CEF1188B for ; Wed, 11 Jan 2017 04:04:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26215 invoked from network); 11 Jan 2017 04:04:43 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Jan 2017 04:04:43 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Tue, 10 Jan 2017 23:04:20 -0500 (EST) Received: (qmail 31110 invoked from network); 11 Jan 2017 04:04:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jan 2017 04:04:19 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 0FB32EC8B81; Tue, 10 Jan 2017 20:04:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS] From: Mark Millard In-Reply-To: <4B492B88-5545-40A2-B611-6D407A00F6C5@gmail.com> Date: Tue, 10 Jan 2017 20:04:18 -0800 Cc: Roman Divacky , Ed Maste , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <16F3E562-44D0-4206-9A38-B849993967DF@dsl-only.net> References: <20161208221452.GA42380@vlakno.cz> <20161212210922.GA27403@vlakno.cz> <613BB28B-46F1-4959-B576-C8AD42A21200@dsl-only.net> <20170107085126.GA82107@vlakno.cz> <2B5FDD60-4D8B-4803-B59C-3C569BA36E68@dsl-only.net> <45C94BFE-4F93-4897-A767-518DACB5D28B@dsl-only.net> <20170108090307.GA3140@vlakno.cz> <1BBC8304-F9E8-4181-A287-11DD8E73B31F@dsl-only.net> <20170108144133.GA19529@vlakno.cz> <5A1FE9C4-684B-43B5-AE26-03C2052E9750@dsl-only.net> <964800DA-213A-4855-A5E7-8C62823E55D5@dsl-only.net> <4B492B88-5545-40A2-B611-6D407A00F6C5@gmail.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 04:04:27 -0000 Hi Justin, On 2017-Jan-10, at 6:26 PM, Justin Hibbits = wrote: > Hi Mark, >=20 > Thanks for all the work you've put into getting FreeBSD/powerpc* = building with clang, it's much appreciated. As time permits I'll be = reviewing and marshalling your patches in. >=20 > The fix for PR 215819 just went in (r311912), and will be MFC'd along = with all the other patches after they're all in HEAD (I chose 2 weeks as = a good ballpark frame). The others will go in as I regression test = them. Thanks. Things that are still odd (know to expect them): A) ld.bfd style ld fails for as.full in buildworld for powerpc64. (I use devel/powerpc64-binutils for buildworld . On a native ppc machine that could be devel/binutils .) Bugzilla 214855 is for this. B) clang++ code for powerpc64 and powerpc does not handle thrown C++ exception correctly and the code crashes. Luckily a lot does not depend on throwing C++ exceptions. While there are FreeBSD bugzilla's for this (multiple fixes needed) there are also llvm ones that likely need to be finished first. C) The powerpc (32-bit) code generation messes up the code ordering relative to when r30 is restored for exiting functions when floating point is involved (at least). For example "df -m" crashes for that reason (conversions between integer types and floating point types). Various ls commands also crash for such issues. (There are more examples.) Booting powerpc (32-bit) has an example r30 problem and ends up in single-user mode but an "exit" lets it continue and complete. (PowerMac G5 so-called "Quad Core" context: I also use it for 32-bit FreeBSD. For now it is the only powerpc that I have access to.) While there is a FreeBSD bugzilla for this general area there are also a llvm one that likely needs to be finished first. Two prior parts of a overall fix are already in place but they missed the r30 handling issue for exiting functions. D) WERROR=3D is in use for my buildkernel activity. I have reported a few things that stop builds without it. E) powerpc (32-bit) uses WITHOUT_LLDB=3D because of 64 bit (8 Byte) atomics being missing but required. F) Various of the patches in bugzilla have relevant notes in the description and the comments for the submittal. If I remember more oddities to expect for can based builds I'll let you know. If you what to see any of my SRC_ENV_CONF files or the scripts that use them (essentially one line scripts but with a long "line" using \ ), just let me know. Similarly for my KERNCONF's (which include the=20 standard ones and then change some things). I've not tried ld.lld yet for anything. But I have set WITH_LLD=3D for a bunch of my builds now. Rebuilding with such completed in all my contexts (even for armv6 and arm64 targets, as well as powerpc). > - Justin =3D=3D=3D Mark Millard markmi at dsl-only.net On Jan 10, 2017, at 3:19 PM, Mark Millard wrote: > I have added the patches to my various historical submittals > and submitted some I'd never made submittals for. >=20 > For the sys/modules/zfs/Makefile I eliminated the extra blank line > that was added in what I showed earlier for the patches. >=20 > Some of the patches are tied to allowing all 3 types of > buidlworld buildkernel contexts in Makefile* 's for > one or both of powerpc64 and powerpc: >=20 > 0) system gcc 4.2.1 and (bootstrapped) system binutils > (not libc++ based) >=20 > 1) devel/powerpc64-xtoolchain-gcc devel/powerpc64-gcc = devel/powerpc64-binutils > (libc++ based, no lib32) >=20 > 2) system clang and devel/powerpc64-binutils or (bootstrapped) system = binutils > (One(?) driven by 3.8.0 that would not be needed for 3.9.1) > (libc++ based) >=20 > Some contexts require options that the others do not. > Some contexts require options that others do not allow and do not = need. >=20 > Some I added note to about potentially using CFLAGS.gcc+=3D and > CFLAGS.clang+=3D instead of conditional logic if the contexts allow > such to be effective. >=20 > The bugzilla numbers (if I found them all): >=20 > 205455 > 206303 > 214904 (the patch allowed building but is not a complete clang/llvm = update) > 215107 > 215681 > 215819 > 215947 > 215948 >=20 > Generally this list excludes things for which WERROR=3D allows the > buildkernel attempts to complete and things related to restrictions > like avoiding lib32 for devel/powerpc64-gcc based builds. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-8, at 9:34 PM, Mark Millard wrote: >=20 > I'll note that: >=20 > Bug 214855 - head -r309179 TARGET_ARCH=3Dpowerpc64 clang 3.9.0 based = cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 = [FreeBSD] 2007-07-03 internal error >=20 > means that I can not use the bootstrap binutils to do buildworld for = powerpc64. > I've confirmed that it still happens in -r311147 . >=20 > So to span both buildkernel and buildworld does require = devel/powerpc64-binutils > or the like for TARGET_ARCH=3Dpowerpc64 . >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-8, at 4:40 PM, Mark Millard = wrote: >=20 > [I've not tried lldb yet but I have good news. . .] >=20 > Well it turns out I was wrong: after the @toc changes (now in the > TOC_REF(...) macro instead of per instruction) I can boot a kernel = built > using the bootstrap system binutils and clang as well. > devel/powerpc64-binutils or the like is not required. >=20 > It looks like bugzilla 215821 is wrong/redundant and 215819 actually > covers the issue. I will likely close 215821 after I've played around > some more. >=20 > I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc = 4.2.1 > as I have things. clang 3.9.1 based builds do not handle throwing C++ > exceptions. lib32 does not work for devel/powerpc64-gcc based builds. >=20 >=20 > As stands I have head -r311147 with: >=20 > # svnlite status /usr/src/ | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/BPIM3-DBG > ? /usr/src/sys/arm/conf/BPIM3-NODBG > ? /usr/src/sys/arm/conf/RPI2-DBG > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > M /usr/src/lib/csu/powerpc64/Makefile > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/ddb/db_main.c (Not relevant) > M /usr/src/sys/ddb/db_script.c (Not relevant) > M /usr/src/sys/modules/zfs/Makefile > M /usr/src/sys/powerpc/aim/trap_subr32.S > M /usr/src/sys/powerpc/include/asm.h > M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant) >=20 > The various KERNCONF's include standard ones then adjust things. > They are not otherwise relevant. >=20 >=20 > Notes on the differences ("M" lines): >=20 > [I do not have a context to test powerpc's kboot or uboot > for powerpc or powerpc64: only PowerMacs. Those Makefile > changes were based on avoiding build errors that occurred > before the change (long ago). I've not gone back through > the armv6(/v7) and arm64 builds recently but historically > they have worked on the rpi2, bpim3, and pine64 with the > boot/uboot/Makefile.inc change in place.] >=20 >=20 > llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s > incomplete patch for the e500 instructions. It was > sufficient to let me continue. >=20 >=20 > The various Makefile*'s and *.mk's deal with: >=20 > -mlongcall (gcc) vs. not (clang) >=20 > -m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new) >=20 > -mcpu=3Dpowerpc64 and -Wa,-mppc64bridge in a Makefile > (kboot) that TARGET_ARCH=3Dpowerpc tried to build and > failed: delete the usage of these options. (No test > validation of built kboot result!) >=20 > -Wa,many for gcc vs. no-such for clang >=20 >=20 > sys/conf/kern.mk deals with: >=20 > -mllvm -disable-ppc-float-in-variadic=3Dtrue (older clang) > vs. > -msoft-float (newer clang) >=20 >=20 > sys/modules/zfs/Makefile deals with: >=20 > -mminimial-toc (gcc) vs. no-such (clang) >=20 >=20 > sys/ddb/db_main.c and sys/ddb/db_script.c : >=20 > These would not be included. (They set up to execute > a built-in default script so I get information for > early boot issues from before ddb takes input.) >=20 >=20 > sys/powerpc/aim/trap_subr32.S deals with: >=20 > Have a cmp instruction be explicit by adding a "0, ". > (This is a TARGET_ARCH=3Dpowerpc issue, not a > TARGET_ARCH=3Dpowerpc64 issue.) >=20 >=20 > sys/powerpc/include/asm.h deals with: >=20 > Have TOC_REF(...) also include @toc in the notation > that results. Have a TOC_NAME_FOR_REF(...) that only > adds the .L to the name passed in and use it where > appropriate. >=20 >=20 > sys/powerpc/ofw/ofw_machdep.c : >=20 > This would not be included. (It is a PowerMac G5 specific > workaround for a openfirmware vs. FreeBSD conflict that > makes booting unreliable for standard FreeBSD builds.) >=20 >=20 >=20 > The details that are not driven by PowerMac G5 specifics > look like: >=20 > 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 311147) > +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working = copy) > @@ -2336,6 +2336,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 > Index: /usr/src/lib/csu/powerpc64/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/lib/csu/powerpc64/Makefile (revision 311147) > +++ /usr/src/lib/csu/powerpc64/Makefile (working copy) > @@ -5,19 +5,20 @@ > SRCS=3D crt1.c crti.S crtn.S > OBJS=3D ${SRCS:N*.h:R:S/$/.o/g} > OBJS+=3D Scrt1.o gcrt1.o > +.include > +.if ${COMPILER_TYPE} =3D=3D "gcc" > CFLAGS+=3D -I${.CURDIR}/../common \ > -I${.CURDIR}/../../libc/include \ > -mlongcall > +.else > +CFLAGS+=3D -I${.CURDIR}/../common \ > + -I${.CURDIR}/../../libc/include > +.endif >=20 > # XXX: See the log for r232932 as to why the above -mlongcall is = needed. Since > # clang doesn't support -mlongcall, and testing shows a clang linked = with a > # clang-built csu segfaults, this must currently be compiled with gcc. = Once > # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. > -.include > -.if ${COMPILER_TYPE} !=3D "gcc" > -CC:=3D gcc > -COMPILER_TYPE:=3D gcc > -.endif >=20 > FILES=3D ${OBJS} > FILESMODE=3D ${LIBMODE} > Index: /usr/src/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/ofw/Makefile.inc (revision 311147) > +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/powerpc/Makefile.inc (revision 311147) > +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,6 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/kboot/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/boot/powerpc/kboot/Makefile (revision 311147) > +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) > @@ -68,8 +68,6 @@ > LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a > .endif >=20 > -CFLAGS+=3D -mcpu=3Dpowerpc64 > - > # Always add MI sources > .PATH: ${.CURDIR}/../../common = ${.CURDIR}/../../../libkern > .include "${.CURDIR}/../../common/Makefile.inc" > @@ -85,9 +83,6 @@ >=20 > LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc >=20 > -# 64-bit bridge extensions > -CFLAGS+=3D -Wa,-mppc64bridge > - > # Pull in common loader code > #.PATH: ${.CURDIR}/../../ofw/common > #.include "${.CURDIR}/../../ofw/common/Makefile.inc" > Index: /usr/src/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/uboot/Makefile.inc (revision 311147) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/src/sys/conf/Makefile.powerpc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/Makefile.powerpc (revision 311147) > +++ /usr/src/sys/conf/Makefile.powerpc (working copy) > @@ -39,7 +39,11 @@ > # Force __SPE__, since the builtin will be removed later with -mno-spe > CFLAGS+=3D -mabi=3Dspe -D__SPE__ > .endif > +.if ${COMPILER_TYPE} =3D=3D "gcc" > CFLAGS+=3D -msoft-float -Wa,-many > +.else > +CFLAGS+=3D -msoft-float > +.endif >=20 > # Build position-independent kernel > CFLAGS+=3D -fPIC > Index: /usr/src/sys/conf/kern.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kern.mk (revision 311147) > +++ /usr/src/sys/conf/kern.mk (working copy) > @@ -162,7 +162,11 @@ > # > .if ${MACHINE_CPUARCH} =3D=3D "powerpc" > CFLAGS+=3D -mno-altivec > +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 > CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue > +.else > +CFLAGS.clang+=3D -msoft-float > +.endif > CFLAGS.gcc+=3D -msoft-float > INLINE_LIMIT?=3D 15000 > .endif > Index: /usr/src/sys/conf/kmod.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/conf/kmod.mk (revision 311147) > +++ /usr/src/sys/conf/kmod.mk (working copy) > @@ -147,8 +147,12 @@ > .endif >=20 > .if ${MACHINE_CPUARCH} =3D=3D powerpc > +.if ${COMPILER_TYPE} =3D=3D "gcc" > CFLAGS+=3D -mlongcall -fno-omit-frame-pointer > +.else > +CFLAGS+=3D -fno-omit-frame-pointer > .endif > +.endif >=20 > .if ${MACHINE_CPUARCH} =3D=3D mips > CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls > 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 311147) > +++ /usr/src/sys/modules/zfs/Makefile (working copy) > @@ -93,9 +93,16 @@ > CFLAGS+=3D-I${SUNW}/common > CFLAGS+=3D-DBUILDING_ZFS >=20 > + > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > +.include > +.if ${COMPILER_TYPE} =3D=3D "gcc" > +# gcc421 requires the -mminimal-toc . > +# But clang 3.9.1 disallows it and does not need it. > +# more modern gcc's allow it. > CFLAGS+=3D-mminimal-toc > .endif > +.endif >=20 > .ifdef ZFS_DEBUG > CFLAGS+=3D-DDEBUG=3D1 > Index: /usr/src/sys/powerpc/aim/trap_subr32.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/aim/trap_subr32.S (revision 311147) > +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) > @@ -406,7 +406,7 @@ > mtctr %r1 /* load counter */ > im1: > lwzu %r1, 8(%r2) /* get next pte */ > - cmp 0, %r1, %r3 /* see if found pte */ > + cmp 0, 0, %r1, %r3 /* see if found pte */ > bdnzf 2, im1 /* dec count br if cmp ne and if > * count not zero */ > bne instr_sec_hash /* if not found set up second = hash > Index: /usr/src/sys/powerpc/include/asm.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/powerpc/include/asm.h (revision 311147) > +++ /usr/src/sys/powerpc/include/asm.h (working copy) > @@ -89,10 +89,11 @@ > name: >=20 > #ifdef __powerpc64__ > -#define TOC_REF(name) __CONCAT(.L,name) > +#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name) > +#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc > #define TOC_ENTRY(name) \ > .section ".toc","aw"; \ > - TOC_REF(name): \ > + TOC_NAME_FOR_REF(name): \ > .tc name[TC],name > #endif >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2017-Jan-8, at 6:41 AM, Roman Divacky wrote: >=20 > Mark, >=20 > Would you be interested in trying lld? It has some support for = ppc/ppc64, which > is probably quite incomplete but it would be nice to know what exactly = is > missing. >=20 > We also have some people (emaste@, davide@) that have non-trivial lld = knowledge > so perhaps progress can be achieved on this side easily? >=20 > Roman >=20 > On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: >> [I forgot to indicate that I still can not use the system = bootstrapped >> ld command and so there is a reason that I used = devel/powerpc64-binutils.] >>=20 >> On 2017-Jan-8, at 2:24 AM, Mark Millard = wrote: >>=20 >>> On 2017-Jan-8, at 1:03 AM, Roman Divacky = wrote: >>>=20 >>>> I think we should add the @toc notations to all the places where = it's needed. >>>> Can you submit such a patch (perhaps with the one for adding 0 to = the cmp >>>> instruction) so they can be committed to FreeBSD repo? >>>=20 >>> In order to test I added @toc to each of the 10 instructions instead >>> of adjusting the macros so that instructions would automatically >>> get the notation but other (what are now) TOC_REF(...) usage would >>> not that should not. >>>=20 >>> I suspect Nathan and Justin might prefer a more automatic >>> alternative so that TOC_REF(...) in an instruction would >>> be sufficient without an explicit @toc in the instruction. >>>=20 >>> I'll see about switching to such code before providing a >>> patch. I'd include the "0, " update to the cmp instruction. >>>=20 >>> But adding @toc's in those instructions (with prior workarounds >>> as well) did allow me to build a bootable system based on using >>> devel/powerpc64-binutils and clang 3.9.1 for both buildworld >>> and buildkernel --still using clang's internal assembler. >>>=20 >>> One issue is that clang does not support (or need) the >>> -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 >>> requires it. For sys/modules/zfs/Makefile my source >>> currently does not support gcc 4.2.1 without editing. >>> As I remember devel/powerpc64-gcc >>> (devel/powerpc64-xtoolchain-gcc) does not require the >>> -mminimal-toc either. But devel/powerpc64-gcc does >>> allow -mminimal-toc so it can be a clang vs. gcc based >>> choice. >>>=20 >>> I might also deal with that before providing patches. >>>=20 >>> Note: -mlongcall was also not needed nor used for clang. >>> (Still used for gcc.) >>>=20 >>> sys/boot/powerpc/kboot/Makefile has a -mcpu=3Dpowerpc64 >>> and -Wa,-mppc64bridge that I eliminated (they messed up >>> 32-bit powerpc builds) but I've no way to test kboot that >>> I know of. This patch might be rejected. >>>=20 >>> Remember that I got this far in part by using your partial >>> e500-instructions patch. I can provide my variant that >>> is a diff with -r311147 instead of an older place in the >>> history. But it would be incomplete coverage of those 2 >>> instructions in clang. >>>=20 >>> Also I build with a workaround for PowerMac G5 boot >>> reliability since OpenFirmware and FreeBSD interact >>> badly at times on PowerMac G5's. This I would not >>> provide as it is PowerMac G5 specific. >>>=20 >>>> If gnu as warns and llvm assembler does the wrong thing without = @toc and both >>>> do the correct thing with @toc I think it's an obvious decision. >>>=20 >>> My choice would be to supply the @toc notation in some way, >>> not necessarily the form I used for the initial test. >>>=20 >>>> Also, with all these changes. Does clang compiled kernel boot? >>>=20 >>> The PowerMac G5 so-called "Quad Core" that I currently have access >>> to is now running from buildworld and buildkernel based on >>> devel/powerpc64-binutils and clang 3.9.1 : >>>=20 >>> Copyright (c) 1992-2017 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 >>> = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc >>> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based = on LLVM 3.9.1) >>> . . . >>>=20 >>> # uname -apKU >>> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat = Jan 7 16:55:01 PST 2017 = markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.= powerpc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 = 1200019 >>>=20 >>> I've built about a dozen ports on it after booting but I've not >>> done a self-hosted buildworld buildkernel yet. >>>=20 >>> [Note: Anything dependent on throwing C++ exceptions in >>> code generated by clang++ 3.9.1 is broken.] >>=20 >> I should have been explicit: >>=20 >> I still can not use the system bootstrapped ld command >> and such binutils for buildkernel and so there is a >> reason that I used devel/powerpc64-binutils instead. >>=20 >> Thus even with my patches clang 3.9.1 would not be ready >> for general use or for a default way of building. I >> have to have a tailored SRC_ENV_CONF file or the like >> still --and a port built and installed. >>=20 >> [On a powerpc64 system devel/binutils could be used.] >>=20 >> There is also the issue with throwing C++ exceptions >> in code when clang 3.9.1 was the code generator used. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: >>> [Top post about FreeBSD bugzilla 215819 and llvm bugzilla >>> 31574 submittals for the issue involved.] >>>=20 >>> My guess is that FreeBSD will view this as a kernel >>> source code issue and not as a toolchain issue. But >>> it is only a guess on my part. >>>=20 >>>=20 >>> I have submitted llvm bugzilla 31574 for this issue. It >>> includes example .S file content that shows the "problem" >>> in the generated .o file (form FreeBSD's view point). >>> (I've no clue how llvm views its criteria relative to this >>> mismatch with gcc/binutils.) >>>=20 >>> Because FreeBSD source code changes (being explicit about >>> @toc) avoid the distinction between clang and gcc/binutils >>> I've not added 31574 to the Depends on list for llvm 25780 >>> (the FreeBSD system compiler issues META entry in llvm). >>>=20 >>> Someone with official status for FreeBSD could add 31574 to >>> llvm's 25780 if FreeBSD wants to push llvm to match >>> gcc/binutils for "@toc notation missing". >>>=20 >>> Otherwise this is a kernel source code issue (as I would >>> guess) and not a toolchain issue. >>>=20 >>> Ed Maste or someone like that likely would make the final >>> decision. >>>=20 >>>=20 >>> I've added to FreeBSD Bugzilla 215819 the new information, >>> including the simple example .S file content that shows the >>> problem in the generated .o file. (Comments #3 and #4 >>> have the new material.) >>>=20 >>> My guess is that FreeBSD Bugzilla 215819 should no longer >>> be assigned to freebsd-toolchain@FreeBSD.org . Instead it >>> would be a powerpc64 kernel source code issue if I'm right. >>>=20 >>> Ed Maste or someone like that likely would make this final >>> decision as well. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> On 2017-Jan-7, at 3:12 PM, Mark Millard = wrote: >>>=20 >>>> [I've supplied a list of places that adding @toc notation should >>>> make clang 3.9.1 targeting powerpc64 do the right thing for >>>> this issue.] >>>>=20 >>>> On 2017-Jan-7, at 2:07 PM, Mark Millard = wrote: >>>>=20 >>>>> On 2017-Jan-7, at 12:51 AM, Roman Divacky = wrote: >>>>>=20 >>>>>> That's a great progress. Can you produce minimal self contained = test case that >>>>>> exhibits this bug? And submit it to llvm bugzilla? >>>>>>=20 >>>>>> Also, clang3.9 defaults to using it's own internal asm, what = happens if you >>>>>> add -no-integrated-as to CFLAGS and recompile the kernel? That = should remove >>>>>> this llvm assembly problem. Does it boot? >>>>>>=20 >>>>>> Thanks Mark, really great progress. >>>>>>=20 >>>>>> Roman >>>>>=20 >>>>> In attempting this I found how to control the behavior based on >>>>> the assembler notation @toc being missing vs. being present. >>>>>=20 >>>>> If llvm should change is strongly tied to llvm's criteria for >>>>> gcc compatibility relative to filling-in/defaulting omitted >>>>> @toc's in the assembler notation. >>>>>=20 >>>>> FreeBSD has the option of always being explicit with @toc in order >>>>> to avoid differences in handling of omitted notation. >>>>>=20 >>>>> So I've no clue if FreebSD wants to claim that a llvm change >>>>> is a requirement for using clang as the powerpc64 system compiler. >>>>>=20 >>>>> [The issue of the distinction is submittable to llvm either way.] >>>>>=20 >>>>> Details. . . >>>>>=20 >>>>> For: >>>>>=20 >>>>> .section ".toc","aw" >>>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>>> . . . >>>>> /* Set up the stack pointer */ >>>>> ld %r1,tmpstk.L(%r2) >>>>>=20 >>>>> using devel/powerpc64-gcc gets: >>>>>=20 >>>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ >=20 >>=20 >>>=20 >>>>=20 >>>>> = locore64_simplified.S >>>>> locore64_simplified.S: Assembler messages: >>>>> locore64_simplified.S:80: Warning: assuming @toc on symbol >>>>>=20 >>>>> and produces (with R_PPC64_TOC16_DS for .toc): >>>>>=20 >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r = locore64_simplified.o >>>>>=20 >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>>=20 >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>>=20 >>>>>=20 >>>>> By contrast clang is silent (cross compiler used): >>>>>=20 >>>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ >=20 >>=20 >>>=20 >>>>=20 >>>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>>=20 >>>>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: >>>>>=20 >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r = locore64_simplified.o | more >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>>=20 >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_ADDR16_DS .toc >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>>=20 >>>>>=20 >>>>>=20 >>>>> But for: >>>>>=20 >>>>> .section ".toc","aw" >>>>> tmpstk.L: .tc tmpstk[TC],tmpstk >>>>> . . . >>>>> /* Set up the stack pointer */ >>>>> ld %r1,tmpstk.L@toc(%r2) >>>>>=20 >>>>> (note the @toc notation) both compilers agree and use >>>>> R_PPC64_TOC16_DS for the .toc: >>>>>=20 >>>>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ = = = -c \ = = = = -x assembler-with-cpp \ = = = = -pipe \ >=20 >>=20 >>>=20 >>>>=20 >>>>> = locore64_simplified.S >>>>>=20 >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r = locore64_simplified.o | more >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>>=20 >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>>=20 >>>>>=20 >>>>> # = /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/= cc \ = = -target = powerpc64-unknown-freebsd12.0 \ = = = = --sysroot=3D/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/= tmp \ = = = -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bi= n \ >=20 >>=20 >>>=20 >>>>=20 >>>>> = -c \ = = = = -x assembler-with-cpp \ = = = -pipe \ = = = = locore64_simplified.S >>>>>=20 >>>>> # /usr/local/powerpc64-freebsd/bin/objdump -r = locore64_simplified.o | more >>>>> locore64_simplified.o: file format elf64-powerpc-freebsd >>>>>=20 >>>>> RELOCATION RECORDS FOR [.text]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 >>>>> 0000000000000046 R_PPC64_TOC16_DS .toc >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.toc]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 tmpstk >>>>>=20 >>>>>=20 >>>>> RELOCATION RECORDS FOR [.opd]: >>>>> OFFSET TYPE VALUE >>>>> 0000000000000000 R_PPC64_ADDR64 .__start >>>>> 0000000000000008 R_PPC64_TOC *ABS* >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I omitted "-f -gdwarf-2" to simplify things but with such >>>>> clang complains about: >>>>>=20 >>>>> locore64_simplified.S:36:2: warning: DWARF2 only supports one = section per compilation unit >>>>> .section ".toc","aw" >>>>> ^ >>>>> locore64_simplified.S:47:2: warning: DWARF2 only supports one = section per compilation unit >>>>> .section ".opd","aw" >>>>> ^ >>>>>=20 >>>>> (buildkernel gets such messages.) >>>>>=20 >>>>>=20 >>>>> I expect I can simplify the .S code more than I have so far but >>>>> I figured I'd report the discovery of the choice FreeBSD needs >>>>> to make for powerpc64 for if llvm changes are to be required >>>>> vs. not. >>>>=20 >>>> The following should be a list of the places that adding @toc usage >>>> would fix some things for using clang 3.9.1 to target powerpc64: >>>>=20 >>>> # grep "@toc[^b]" = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain_kernel-amd64-host-2017-01-03:23:48:41 | more >>>> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc = on symbol >>>> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc = on symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on = symbol >>>> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc = on symbol >>>>=20 >>>> devel/powerpc64-gcc and devel/powerpc64-binutils together happens = to report >>>> on missing @toc 's. >>>>=20 >>>> But, of course, if some sections of code are conditionally compiled = and >>>> excluded above they would not be listed. >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>=20 >>> _______________________________________________ >>> 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" >>=20 >> _______________________________________________ >> 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" >=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" >=20 >=20 From owner-freebsd-ppc@freebsd.org Wed Jan 11 09:15:41 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC555CAA4AC for ; Wed, 11 Jan 2017 09:15:41 +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 A1FE416F1 for ; Wed, 11 Jan 2017 09:15:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22976 invoked from network); 11 Jan 2017 09:15:39 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Jan 2017 09:15:39 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 11 Jan 2017 04:15:39 -0500 (EST) Received: (qmail 7246 invoked from network); 11 Jan 2017 09:15:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jan 2017 09:15:39 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id EFFF2EC8FBA; Wed, 11 Jan 2017 01:15:38 -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.2 \(3259\)) Subject: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 Message-Id: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> Date: Wed, 11 Jan 2017 01:15:38 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain To: Roman Divacky X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:15:42 -0000 [Note that the /usr/bin/ld.lld here was built via buildworld on the powerpc64 machine: native build, not a cross build.] Roman Divacky had suggested: From: Roman Divacky Date: January 8, 2017 at 6:41:33 AM PST > Would you be interested in trying lld? It has some support for = ppc/ppc64, which > is probably quite incomplete but it would be nice to know what exactly = is > missing. Here it goes for using lld to link a trivial program on a powerpc64 machine targeting a powerpc64 machine. . . # uname -apKU FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311147M: Tue Jan = 10 19:58:19 PST 2017 = root@FBSDG5L:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.power= pc64/usr/src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200019 1200019 (System built using WITH_LLD=3D but WITHOUT_LLD_AS_LD=3D ) (System built using devel/powerpc64-binutils , not the bootstrap system binutils. Could have been devel/binutils since it was on powerpc64 for the build.) (The system ld fails for as.full linking during buildworld.) # more main.c int main () { return 0; } # clang -v -fuse-ld=3Dlld main.c FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj = -mrelax-all -disable-free -main-file-name main.c -mrelocation-model = static -mthread-model posix -mdisable-fp-elim -masm-verbose = -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v -v -v = -dwarf-column-info -debugger-tuning=3Dgdb -resource-dir = /usr/bin/../lib/clang/3.9.1 -fdebug-compilation-dir /root/c_tests = -ferror-limit 19 -fmessage-length 200 -fno-signed-char = -fobjc-runtime=3Dgnustep -fdiagnostics-show-option -fcolor-diagnostics = -o /tmp/main-0d483e.o -x c main.c clang -cc1 version 3.9.1 based upon LLVM 3.9.1 default target = powerpc64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/3.9.1/include /usr/include End of search list. "/usr/bin/ld.lld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 = --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o = /usr/lib/crtbegin.o -L/usr/lib /tmp/main-0d483e.o -lgcc --as-needed = -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o # ./a.out ld-elf.so.1: assert failed: = /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 Abort trap (core dumped) It stopped at the assert in: int reloc_plt(Obj_Entry *obj) { const Elf_Rela *relalim; const Elf_Rela *rela; if (obj->pltrelasize !=3D 0) { relalim =3D (const Elf_Rela *)((char *)obj->pltrela + obj->pltrelasize); for (rela =3D obj->pltrela; rela < relalim; rela++) { assert(ELF_R_TYPE(rela->r_info) =3D=3D = R_PPC_JMP_SLOT); =20 if (reloc_plt_object(obj, rela) < 0) { return (-1); } } } return (0); } By contrast: # clang -v main.c FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on = LLVM 3.9.1) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj = -mrelax-all -disable-free -main-file-name main.c -mrelocation-model = static -mthread-model posix -mdisable-fp-elim -masm-verbose = -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v = -dwarf-column-info -debugger-tuning=3Dgdb -resource-dir = /usr/bin/../lib/clang/3.9.1 -fdebug-compilation-dir /root/c_tests = -ferror-limit 19 -fmessage-length 200 -fno-signed-char = -fobjc-runtime=3Dgnustep -fdiagnostics-show-option -fcolor-diagnostics = -o /tmp/main-895416.o -x c main.c clang -cc1 version 3.9.1 based upon LLVM 3.9.1 default target = powerpc64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/3.9.1/include /usr/include End of search list. "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 = --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o = /usr/lib/crtbegin.o -L/usr/lib /tmp/main-895416.o -lgcc --as-needed = -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o # ./a.out (No failure.) =46rom what I've seen on the lists it appears that powerpc64's lld effort may well have not even started yet so getting even this far might be good news. I'm not sure it is considered far enough along to classify this as an error yet: it may be as expected. As for the ordering: tier-1 and near tier-1 that is modern (armv6, possibly arm64?) likely comes before tier-2. I've no clue for mips family vs. powerpc family. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Jan 13 00:30:03 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2F97CAC104 for ; Fri, 13 Jan 2017 00:30:03 +0000 (UTC) (envelope-from gabriel.diaz@vgtelecomreports.com) Received: from smtp.vgtelecomreports.com (smtp.vgtelecomreports.com [202.0.103.19]) by mx1.freebsd.org (Postfix) with ESMTP id D58471593 for ; Fri, 13 Jan 2017 00:29:59 +0000 (UTC) (envelope-from gabriel.diaz@vgtelecomreports.com) X-SmarterMail-Authenticated-As: admin@vgtelecomreports.com DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; d=vgtelecomreports.com; s=smtp; h=received:from:to:message-id:subject:date:mime-version:reply-to :content-type; b=EUCaWkBRrqGEpQSfvg8sPchLZpxZWPb4oYyvF2k6Yesv7QaZPKmxVmhKK/yKXFP5q H7zXM5pAojBZBhOzZEzAkoCPk9foQHNyyp4baaeRmu4wAYs0naXjCNlRpjGKQGJPe 62KWZCHPh4pP7rT6mF5SGz9VanvV1hwbA/wvPh4tY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vgtelecomreports.com; s=smtp; h= content-type:reply-to:mime-version:date:subject:message-id:to:from; bh=WuuAasSchHJtU6KF3Tqsfb8JiKngbLykJl44/s33rnM=; b=HVl3i0hz+Y1FB6h34xjj3KpBw4xSZHWDKXS0QBPJ4J69IkGgpLtBz+Quw/xqhwqCA 79hw9pmMJ9hMTSycM+gxzmeb79tT0qm31M0w8fe+KPxvvf8OQOMQUhZP8yEmWK5Mn rtL3psKuNxIPRGVjCPlvpLFIunzMKVvdVjfAXeqT8= Received: from WIN-ASQ29B6R1EP (WIN-ASQ29B6R1EP [202.0.103.127]) by smtp.vgtelecomreports.com with SMTP; Thu, 12 Jan 2017 20:09:05 +0000 From: Gabriel Diaz To: freebsd-ppc@freebsd.org Message-Id: <20170112200905.-1730833040@vgtelecomreports.com> Subject: Internet of Things (IoT) Market Report 2017-2022 Date: Thu, 12 Jan 2017 20:09:05 +0000 MIME-Version: 1.0 Reply-To: gabriel.diaz@vgtelecomreports.com Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:30:03 -0000 Visiongain - Business Report Updates Speak to our consultant now: +44 (0)20 7549 9933 Internet of Things (IoT) Market Report 2017-2022 Analysis of Machine to Machine (M2M), Big Data & Cloud Technologies. Forecasts For Consumer Electronics (Smartphones, Smart Home, Energy & Utilities, Safety & Security, Smart Appliances, Connected Devices) Industrial (Oil & Energy, Agriculture, Retail, Manufacturing) Automotive & Transportation (Aviation, Maritime, Connected Vehicles) Healthcare (Telemedicine, Fitness & Activity) Other (Fixed Broadband, Fixed Communications, Government) The Internet of Things market is set to be worth $1,128.4 billion in 2017, driven by the increasing number of IoT applications. The report describes trends in the market both quantitatively and qualitatively. IoT has the potential to have a transformative impact on everything from inventory items to vending machines to connected cars and is the cornerstone in ideas such as connected homes and the smart grid. Between eco-friendly applications, money saving services and enterprise transformation, we believe the demand for the Internet of Things is set to soar over the forecast period. Not only will the Internet of Things and M2M market flourish, many IT and Telecom based industries will see huge growth with the widespread application of the Internet of Things, especially wireless infrastructure, big data and cloud computing. How this 121 page report delivers: • Global Internet of Things market forecasts from 2017-2022 • Regional Internet of Things market forecasts from 2017-2022 covering Asia-Pacific, Latin America, Europe, Middle East and Africa, and North America; • Country level Internet of Things forecasts from 2017-2022 covering China, the USA, Japan, France, the UK, Germany, India, Russia, Italy, and Brazil • Internet of Things submarket forecasts from 2017-2022 covering: Industrial IoT, Automotive & Transportation IoT, Healthcare IoT, Consumer Electronics IoT and Others IoT. • Analysis of the key factors driving growth in the global and regional/country level Internet of Things markets from 2017-2022 • Profiles of the leading players and what their prospects are over the forecast period • Analysis of game changing technological trends being employed by the leading players and how these will shape the Internet of Things industry. • SWOT analysis of the major strengths and weaknesses of the market, together with the opportunities available and the key threats faced. • Market conclusions & recommendations. • 3 Full transcripts of exclusive Visiongain interviews with key opinion-leaders in the market, from the following companies: • Able Device • Humavox • PTC For more information & orders please contact gabriel.diaz@vgtelecomreports.com How to purchase our reports Select the license from the list below and send your details Licensing options: Single User GBP 1999 Dept. (5 Users) GBP 2999 Site GBP 4999 Global GBP 6999 Buy this report Want to know more? Send me more info Table of Contents - Internet of Things (IoT) Market Report 2017-2022 1. Executive Summary 2. Introduction to the Internet of Things Market 2..1 What Defines the Internet of Things? 2.2 M2M Technology is the Backbone behind the Massive Potential in the Internet of Things Market 2.2.1 M2M History and Recent Developments 2.3 A Benefits Derived From Internet of Things 2.4 Cloud to Play Pivotal Role in the Internet of Things Industry Boom 2.5 Growth in the Wireless Sector 3. Global Internet of Things Market 3.1 Market Definition 3.1.1 Internet of Things Submarket Segmentation 3.2 Global Internet of Things Market Forecast 2017-2022 3.3 Global Internet of Things Connections Forecast 2017-2022 4. Global Internet of Things Submarket Forecasts 2017-2022 4.1 What are the Leading Submarkets in Visiongain’s Internet of Things Revenue Forecast 2017-2022? 4.1.1 Global Internet of Things Revenue Submarket Forecast AGR & CAGR 4.1.2 Consumer Electronics IoT Submarket Leading the Internet of Things with a Market Share of 30.1% In 2017 4.2 Industrial IoT 4.2.1 Industrial Internet of Things Submarket Forecast Summary 2017-2022 4.3 Automotive & Transportation IoT 4.3.1 Automotive & Transportation IoT Submarket Forecast Summary 2017-2022 4.4 Healthcare IoT 4.4.1 Healthcare IoT Submarket Forecast Summary 2017-2022 4.5 Consumer Electronics IoT 4.5.1Consumer Electronics IoT Submarket Forecast Summary 2017-2022 4.6 Others IoT Submarket Forecast Summary 2017-2022 5. Regional Internet of Things Forecasts 2017-2022 5.1 Overview 5.2 Asia Pacific Leading Region in Terms of Revenue in 2017 5.2.1 Regional Internet of Things Revenue Forecast AGR & CAGR 5.2.2 Asia Pacific Leading Regional Internet of Things Market Shares in 2017 with 36.4% 5.3 Top 10 National Internet of Things Market Forecasts 2017-2022 6. SWOT Analysis of the IoT Market 2017 7. Expert Opinion on the IoT Market 7.1 Able Device 7.1.1 Able Device Internet of Things Portfolio 7.1.2 Able Device Strengths in the Internet of Things Market 7.1.3 Key Trends & Developments in the Internet of Things Market 7.1.4IoT Submarkets Focal to Able Device’s growth in the sector 7.1.5 Able Device’s Most Sought After IoT Solutions 7.1.6 Regional Growth in the Internet of Things Market 7.1.7 Primary Drivers & Restraints of the Internet of Things Market 7.1.8 Technological Developments in the Internet of Things Market 7.1.9 Opportunities and Challenges in the Internet of Things Market 7.1.10 Evolution of IoT Market and Future Prospects 7.2 Humavox 7.2.1 Humavox Device Internet of Things Portfolio 7.2.2 Humavox Strengths in the Internet of Things Market 7.2.3 Key Trends & Developments in the Internet of Things Market 7.2.4 IoT Submarkets Focal to Humavox’s growth in the sector 7.2.5 Humavox’s Most Sought After IoT Solutions 7.2.6 Regional Growth in the Internet of Things Market 7.2.7 Primary Drivers & Restraints of the Internet of Things Market 7.2.8 Technological Developments in the Internet of Things Market 7.2.9 Evolution of IoT Market and Future Prospects 7.3 PTC 7.3.1 PTC Internet of Things Portfolio 7.3.2 PTC Strengths in the Internet of Things Market 7.3.3 Key Trends & Developments in the Internet of Things Market 7.3.4 IoT Submarkets Focal to PTC’s growth in the sector 7.3.5 PTC’s Most Sought after IoT Solutions 7.3.6 Regional Growth in the Internet of Things Market 7.3.7 Primary Drivers & Restraints of the Internet of Things Market 7.3.8 Technological Developments in the Internet of Things Market 7.3.9 Opportunities and Challenges in the Internet of Things Market 7.3.10 Evolution of IoT Market and Future Prospects 7.3.11 Final Thoughts on the IoT Market 8. Leading Companies in the IoT Market 8.1 Amazon 8.2 Apple 8.2.1 Apple’s IoT Strategy 8.3 ARM 8.4 AT&T 8.4.1 AT&T Business Aims 8.4.2 AT&T’s Position in the Market 8.5 BlackBerry 8.6 China Mobile Company Overview 8.7 Cisco 8.8 Freescale 8.9 General Electric 8.10 Google 8.11 HP 8.12 IBM 8.13 Intel 8.14 Kore Telematics 8.14.1 Kore Telematics Offerings 8.14.2 KORE Partnerships and Strategy Overview 8.15 Microsoft 8.15.1 Retail 8.15.2 Healthcare 8.15.3 Automotive 8.16 Oracle 8.17 PTC 8.18 Qualcomm 8.19 Samsung 8.20 SAP 8.21 Verizon Communications 8.21.1 Verizon’s M2M Solutions and Overall Strategy 8.21.2 Verizon’s Focus on Automotive Industry 8.22 Other Leading Companies in the IoT Market 9. Conclusions 9.1 Internet of Things Market Drivers 9.1.1 Cost savings 9.1.2 Creating New Revenue Streams 9.1.3 Connected Devices Growing Rapidly 9.1.4 IoT Gaining Popularity 9.2 Internet of Things Market Opportunities 9.2.1 Enhanced Market Segmentation 9.2.2 IoT Can be Expanded to Any Vertical 9.2.3 Network Coverage 9.2.4 Telematics and Telemetry Increasing Efficiency 9.2.5 Service Providers Need to Expand Offerings 9.2.6 M2M Creating Scope for Development of New Applications 9.3 Internet of Things Market Challenges 9.3.1 Lack of Universal Standards 9.3.2 Security Concerns 9.3.3 IoT Solutions Can Be Expensive 9.3.4 Limited Awareness 9.4 Way Forward 9.4.1 Increase in M2M Partnerships 9.4.2 Standardisation 9.4.3 Measuring Data 9.4.4 New Business Models 10. Glossary List of Tables Table 3.1 Global Internet of Things Market Forecast 2017-2022 ($ billion, AGR %, CAGR%, Cumulative) Table 3.2 Global Internet of Things Connections Forecast 2017-2022 (billion, AGR %, CAGR%, Cumulative) Table 4.1 Global Internet of Things Revenue Submarket Forecast 2017-2022 ($billion) Table 4.2 Global Internet of Things Submarket AGR Forecast 2018-2022 (AGR %) Table 4.3 Global Internet of Things Revenue Submarket CAGR Forecast (%) 2017-2020, 2020-2022, and 2017-2022 Table 4.4 Global Internet of Things Market Share Forecast by Type 2017-2022 (%) Table 4.5 Industrial Internet of Things Submarket Revenue Forecast 2017-2022 ($ billion, AGR %, CAGR%, Cumulative) Table 4.6 Automotive & Transportation IoT Submarket Revenue Forecast 2017-2022 ($ billion, AGR %, CAGR%, Cumulative) Table 4.7 Healthcare IoT Submarket Revenue Forecast 2017-2022 ($ billion, AGR %, CAGR%, Cumulative) Table 4.8 Consumer Electronics IoT Submarket Revenue Forecast 2017-2022 ($ billion, AGR %, CAGR%, Cumulative) Table 4.9 Others IoT Submarket Revenue Forecast 2017-2022 ($ billion, AGR %, CAGR%, Cumulative) Table 5.1 Regional Internet of Things Revenue Forecast 2017-2022 ($ billion) Table 5.2 Regional Internet of Things Revenue AGR Forecast 2018-2022 (AGR %) Table 5.3 Regional Internet of Things Revenue CAGR Forecast (%) 2017-2020, 2020-2022, and 2017-2022 Table 5.4 Regional Internet of Things Market Share Forecast 2017-2022 (%) Table 5.5 Top 10 National Internet of Things Market Forecast 2017-2022 ($ Billions, AGR%, % Share) Table 6.1 SWOT Analysis of the Internet of Things Market 2017 Table 8.1 AT&T M2M Solution, Assets, and Advantages Table 8.2 IBM Adept Performance Management Solution Focus Areas Table 8.3 KORE Telematics M2M Connectivity Services Table 8.4 Windows Embedded Product Portfolio Table 8.5 Verizon’s M2M Solutions Table 8.6 Other Leading Companies in the IoT Market 2017 (Company, Product /service) List of Figures Figure 3.1 Internet of Things Submarket Segmentation Figure 3.2 Internet of Things Submarket Segmentation Figure 3.3 Global Internet of Things Market Forecast 2017-2022($ billion, AGR %) Figure 3.4 Global Internet of Things Connections Forecast 2017-2022(billion, AGR %) Figure 4.1 Global Internet of Things Revenue Submarket Forecast 2017-2022 ($ billion) Figure 4.2 Global Internet of Things Revenue Submarket AGR Forecast 2018-2022 (AGR %) Figure 4.3 Global Internet of Things Market Share Forecast by Type 2017 (%) Figure 4.4 Global Internet of Things Market Share Forecast by Type 2020 (%) Figure 4.5 Global Internet of Things Market Share Forecast by Type2022 (%) Figure 4.6 Industrial Internet of Things Submarket Revenue Forecast 2017-2022($ billion, AGR %) Figure 4.7 Industrial Internet of Things Submarket Share Forecast 2017, 2020 and 2022 (% Share) Figure 4.8 Automotive & Transportation IoT Submarket Revenue Forecast 2017-2022($ billion, AGR %) Figure 4.9 Automotive & Transportation IoT Submarket Share Forecast 2017, 2020 and 2022 (% Share) Figure 4.10 Healthcare IoT Submarket Revenue Forecast 2017-2022($ billion, AGR %) Figure 4.11 Healthcare IoT Submarket Share Forecast 2017, 2020 and 2022 (% Share) Figure 4.12 Consumer Electronics IoT Submarket Revenue Forecast 2017-2022($ billion, AGR %) Figure 4.13 Consumer Electronics IoT Submarket Share Forecast 2017, 2020 and 2022 (% Share) Figure 4.14 Others IoT Submarket Revenue Forecast 2017-2022($ billion, AGR %) Figure 4.15 Others IoT Submarket Share Forecast 2017, 2020 and 2022 (% Share) Figure 5.1 Regional Internet of Things Revenue Forecast 2017-2022 ($ billion) Figure 5.2 Regional Internet of Things Revenue AGR Forecast 2018-2022 (AGR %) Figure 5.3 Regional Internet of Things Market Share Forecast 2017 (%) Figure 5.4 Regional Internet of Things Market Share Forecast 2020 (%) Figure 5.5 Regional Internet of Things Market Share Forecast 2022 (%) Figure 5.6 Top 10 National Internet of Things Market Forecast 2017-2022 ($ Billions, AGR%, % Share) Figure 8.1 IBM MessageSight System Figure 8.2 Microsoft Azure Intelligent Systems Companies Mentioned in this Report 7 Layers Able Device Aeris Aeris Communications Aeroscout Alcatel-Lucent Alien Technology Amazon America Movil Apple Arkessa ARM Arrayent AT&T Atos Origin SA Augusta Systems AVIDwireless Axeda Best Buy Blackberry CalAmp CETECOM China Mobile Cisco Clearconnex Coldlight Comtrol Connect One Connected Development Coronis DataOnline DataRemote Dell Deutsche Telekom Digi International Dust Networks Echelon eDevice ei3 Ember Enfora Ericsson Esprida Etisalat Eurotech Exosite Feeney Wireless Freescale Gemalto General Electric (GE) Globalstar Google Honeywell International HP Huawei Hughes Telematics Humavox IBM ILS Technology iMetrik Solutions Inilex Inmarsat Intel Iridium Communications Itron Janus Remote Communications Jasper Wireless Kepware Kore Telematics KPN Laird Technologies Lantronix LG M2M Communications M2M DataSmart Marvell MEMSIC Microchip Technology Microsoft Millenial Net Mocana Morey Motorola MOXA Nestle Netflix Nokia Siemens Networks nPhase NTT Docomo Nvidia NXP Semi Conductors Omnilink Systems Oracle Orange ORBCOMM Palantiri Systems Panasonic Pedigree Technologies Perle Systems Precidia Technologies PTC Qualcomm Quirky Red Bend Software RF Code Inc. RF Monolithics Rogers Rogers Communications Samsung SAP Savi Technology SENA Technologies SensorLogic Sigma Designs SingTel Sixnet SkyTel Sony Sony Ericsson Sprint Swisscom Synchronoss Technologies Telcel Telefonica Telekom Telenor Telit Telstra Telular TELUS Mobility Tendril Networks Texas Instruments ThingMagic ThingWorx Tridium Trimble Tyntec ublox V2COM Verizon VimpelCom Vodafone Vuforia WebTech Wireless Wyless Group Xact Technology Zebra ZTE List of Organisations Mentioned CASAGRAS project Consumer Electronics Show (CES) KAA Project The Alliance for Telecommunications Industry Solutions (ATIS) of the U.S The Association of Radio Industries and Businesses (ARIB) and the Telecommunication Technology Committee (TTC) of Japan The China Communications Standards Association (CCSA) The European Telecommunications Standards Institute (ETSI) The Telecommunications Industry Association (TIA) of the U.S. The Telecommunications Technology Association (TTA) of Korea The UK's Department for Energy and Climate Change (DECC) World Wide Developers Conference Community (WWDC) For more information & orders please contact gabriel.diaz@vgtelecomreports.com Terms and Conditions By replying to this e-mail submitting your order for this product you have agreed without limitation or qualification to be bound by and to comply with these Terms and Conditions. You agree that you will not fail to complete any transaction after submitting an order to purchase a product or submit any order to purchase a product where you do not intend to complete the transaction. Management Reports will only be sent on receipt of payment. Our mailing address is: 230 City Road. EC1V 2QY, London, UK. As a valued contact or customer, you are receiving this email with information that we believe will be relevant to you. If however, you wish to stop future messages you can unsubscribe from this list From owner-freebsd-ppc@freebsd.org Fri Jan 13 10:22:25 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD767CAD6DF for ; Fri, 13 Jan 2017 10:22:25 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4B010E3 for ; Fri, 13 Jan 2017 10:22:25 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by freefall.freebsd.org (Postfix) id DBB39472F; Fri, 13 Jan 2017 10:22:24 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 972B8472E for ; Fri, 13 Jan 2017 10:22:24 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99F031FFE; Fri, 13 Jan 2017 10:22:23 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x243.google.com with SMTP id b22so7830131pfd.3; Fri, 13 Jan 2017 02:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=BB2SwcYJOIYhak/FtbdOn+kdJMNuB3/ApFTDM8vnGGk=; b=d2HZk80lfFDjN3AicwQx/M4a86tTtWJSv1ZUOoJEfLcnbf/SKG4aDwGyCBuHo2WxVm lZLV9gFiKjCx+2FWoaF+rf1c/2LpwBaZYuDlYbFhgU9XdC29ODALkvMMeq0b3SbvGwi3 GawZiSzk6M2+okYpG/5F5g+fqmMHB7PslcJglu2UWCnu35N5lw+HS7w5IUmzwaHppygV fUAxfuBC9+tJOWv5BzgmVgIpvqHUL4kd921HYPZMd2eVoZaQAqNrauzy9sk1rUmYXa/v FP7hok9qpJWuGCtowZr7im2LkuEg1ztgC5sCHgy/m4vB2xHDUIBvpYIwmDk6sgekWQtp i/AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=BB2SwcYJOIYhak/FtbdOn+kdJMNuB3/ApFTDM8vnGGk=; b=I9/FH88bkySBBB8kcV7Ko9HgaS4RcBrwDmC7EETWhxkEq/6Xa4suD/XG3YUmMTdSF8 bpiKTql9PzD1ArgApnXOAii1bkSVvPy4JPuNgRP5sgMgIdTx9/x/EdRjMIiUSJuCSEsY px8qHkGtMaSs1OKPs6Ls04pHeRtQssQ+h7yNRwA1yIaXVYdBDPGZAZooFXP5nj5RCMo5 pB4DPTHtHq7Ly0HQzgN4A/xuWIwfZ9w94QIbfWUugvmF+HQqt+hHdkG4nvWU+W0lta3D WIgxKarUcmATSU29ZmKJT57dVkEwURjlQrUI9DGzIVjkR3Vw1Iw17aj4wxsu43kSWU+z p5yQ== X-Gm-Message-State: AIkVDXLAONg/upmC0KmtJra/YuGYxXxxJdfcf+wY75dSdM4L4p1bjLY/ynmSePXxYeAnYg== X-Received: by 10.99.176.76 with SMTP id z12mr23252924pgo.158.1484302942982; Fri, 13 Jan 2017 02:22:22 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id l63sm28030951pfl.83.2017.01.13.02.22.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 Jan 2017 02:22:22 -0800 (PST) From: "Ngie Cooper (yaneurabeya)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_B949EFCF-91DD-4FB3-8CE8-E1FFF90DB5E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: powerpc.LINT* broken in netmap(4) Date: Fri, 13 Jan 2017 02:22:20 -0800 Message-Id: Cc: FreeBSD CURRENT , freebsd-powerpc@FreeBSD.org, Luigi Rizzo To: freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:22:25 -0000 --Apple-Mail=_B949EFCF-91DD-4FB3-8CE8-E1FFF90DB5E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I spotted these compilation errors on universe12a.freebsd.org = for both powerpc.LINT and powerpc.LINT64: cc1: warnings being treated as errors /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function = 'generic_set_tx_event': /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the = address of 'generic_mbuf_destructor' will always evaluate as 'true' = [-Waddress] --- netmap_generic.o --- *** [netmap_generic.o] Error code 1 I haven=E2=80=99t yet dug into why this only surfaces on = powerpc, yet=E2=80=A6 Thanks, -Ngie --Apple-Mail=_B949EFCF-91DD-4FB3-8CE8-E1FFF90DB5E0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYeKpcAAoJEPWDqSZpMIYVpjEQAKciJGGd2iDNM4s5CNQaaaZt WQMG2gX1fmuluRSWIn1wdgayj7G1lUVEN0vthYJZF+eHYp+8Q4ev/mqFEuX69UFn 9ADtxHdOnbM591HRXMRTPxCOzeMUpbZR2PX0Gk/m+WCc/Zo7gmuN+1YMV1UXl4Od 6onN9D7Trbl7PEB1tDs1g4BfsiccbEekOyTurntE4Ixo39jUfRynM3pvZaEytyr+ HLwyEIVMeAp1vQRj7dHzPsEcjwvU6k3DxpCMPzl0/JEa3Ay1KYUoNlczKs8I2n39 CYjUWmShyBlE530ls7dXDFgejIPNqk6ThpkqPegfZJcHGRzjGUrhiMHXheewvAFr jWXSAimHnP4obMxsLnBpL9msbg6VrUC/CarvQUdaTKc5qrWgCTGxDZLwMb0SC65e YJS+eOH31ePrk0I2Yxl1OdR9Zgx/pC0iAUa045yOOsWtJ/1eR0aAz/o/Ft9I0MEh THwFawLsQTgY8x6YBddxFCRPhEOxML2CwrVOkTbBaZR2CGrs2fU26ii7eKCS4LUo RMd6rqwmoAsOa9BjRV5n4VrQDZOHl+IVG7JvmeC4VocCS17+imer0tXhyn+uVfcr 1u7TaI88+XHzB+YpQ1lYWK5MTLSwQVE9tf+IQHOgSGBR6uIFoWtB7BNzQtWiK69b VnV9/xPu0yc5EUzuKk0j =G382 -----END PGP SIGNATURE----- --Apple-Mail=_B949EFCF-91DD-4FB3-8CE8-E1FFF90DB5E0-- From owner-freebsd-ppc@freebsd.org Fri Jan 13 10:46:30 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CBDACAC4D9 for ; Fri, 13 Jan 2017 10:46:30 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04D87129D for ; Fri, 13 Jan 2017 10:46:30 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by freefall.freebsd.org (Postfix) id 56BBC4F5A; Fri, 13 Jan 2017 10:46:29 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 42FD94F59 for ; Fri, 13 Jan 2017 10:46:29 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60F351286; Fri, 13 Jan 2017 10:46:28 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x241.google.com with SMTP id j15so6353183oih.0; Fri, 13 Jan 2017 02:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CKCgPaMpvPjuihq4SbZxBPn/gb78dk+rbH4DYPY70t8=; b=ecteEl8TxgR063WtQ8ZXsHwCS108tIWwsyDzALJ7moz4yoB+OM8sOFJpkUJMlkpH5F UXBBS9CVkuUnahW8DnQfLfs+0Sf1PJOlY6zARGCTXgYgVib+9rfzwUoRMmLH483L2LTe MNrimSVNIhkbVKIzR8V8OWHAj3WCn4StbyTdw3VSRWH7ntS+W5Lnpb6m/7jDmTJpkA7X sJM4AiHCySYL5vkDmIzFaADjJnVmH9O1HHt96QkWbyi7VDf6gYfvXfBP3PHhV9jF74rI QoHbn97Ap53AMCT6F4hI/7u8qvWdB+qeUj3QZvl41bwXjvD8UP4+rYF7gh52ttDY+eJY eWAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CKCgPaMpvPjuihq4SbZxBPn/gb78dk+rbH4DYPY70t8=; b=Cqsvkem/RwwDHePqoCyVgoGcXES0mzyOJ+ara1DaS/+pQSEgJs7LSfabIvTM545bdh FEOB9kzhCfEHNXCJROvevtMOEC8nCXtaCyYeTn2ZV7PL7Uu9zptnGGI36p58p/V1zKC1 bVOYxscxA8rwSHe1P1lqgGcoKxK1jOBQjwZQy/jrPqe1Y6pdX1ecco+LKqJ66eWCAalQ ESSe9MPDzhHoRBJaKN812+2ENCxbB8c7Be/V1CpF/QWZ0SjD/6MwEAVoE8PQI0UHto4O 3hOu1E1XoLqhrX0F9yCZ747xt9al9Ja6aQo4+Rz/EXcWWMAVCpyHqwzRQGjdCmmfquWZ 92NQ== X-Gm-Message-State: AIkVDXLiXzSl4wTTFtMdRrBMKzJWfodvcTCuvDzYje5Y7cl3S8TfXlw8/kUgD7q7QJZZN9j9MQzmFuP7mJB9yA== X-Received: by 10.202.213.17 with SMTP id m17mr9706157oig.104.1484304387641; Fri, 13 Jan 2017 02:46:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.166 with HTTP; Fri, 13 Jan 2017 02:46:27 -0800 (PST) In-Reply-To: References: From: Vincenzo Maffione Date: Fri, 13 Jan 2017 11:46:27 +0100 Message-ID: Subject: Re: powerpc.LINT* broken in netmap(4) To: "Ngie Cooper (yaneurabeya)" Cc: "freebsd-net@freebsd.org" , freebsd-powerpc@freebsd.org, FreeBSD CURRENT , Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:46:30 -0000 Hi, Thanks for reporting. The warning is innocuous, but I'm not sure how to silence it. Maybe diff --git a/sys/dev/netmap/netmap_generic.c b/sys/dev/netmap/netmap_generic.c index cb1cff1f0e7..226a0864fd0 100644 --- a/sys/dev/netmap/netmap_generic.c +++ b/sys/dev/netmap/netmap_generic.c @@ -168,7 +168,7 @@ nm_os_get_mbuf(struct ifnet *ifp, int len) static void void_mbuf_dtor(struct mbuf *m, void *arg1, void *arg2) { } #define SET_MBUF_DESTRUCTOR(m, fn) do { \ - (m)->m_ext.ext_free =3D fn ? (void *)fn : (void *)void_mbuf_dtor; \ + (m)->m_ext.ext_free =3D (fn !=3D NULL) ? (void *)fn : (void *)void_mbuf_dtor; \ } while (0) static inline struct mbuf * or we could turn SET_MBUF_DESTRUCTOR into a real function. Cheers, VIncenzo 2017-01-13 11:22 GMT+01:00 Ngie Cooper (yaneurabeya) : > Hi, > I spotted these compilation errors on universe12a.freebsd.org for > both powerpc.LINT and powerpc.LINT64: > > cc1: warnings being treated as errors > /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function > 'generic_set_tx_event': > /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the > address of 'generic_mbuf_destructor' will always evaluate as 'true' > [-Waddress] > --- netmap_generic.o --- > *** [netmap_generic.o] Error code 1 > > I haven=E2=80=99t yet dug into why this only surfaces on powerpc,= yet=E2=80=A6 > Thanks, > -Ngie > --=20 Vincenzo Maffione From owner-freebsd-ppc@freebsd.org Fri Jan 13 22:27:55 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E986CAEC92; Fri, 13 Jan 2017 22:27:55 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDDA41E93; Fri, 13 Jan 2017 22:27:54 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id y143so10033940pfb.1; Fri, 13 Jan 2017 14:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=xSH0RWQ0Sc5pYUS471PVPmWO761Qjyq9ND9fXOyzgHc=; b=cpoeN0s3FQd0jii2PoZvChtw97kCVjN60A/LE1Ib7lo6sC/EvegWILBldsTR++J5F8 entDwPY/xZHKj0oJeenuEUDoP+MuNBOZSjz2vsmq7D3/wSf8c6KQisHK/2JmDvkS/+jU x3RMyQF0yGpTRSBJGlJD0CbYWVLfrXvVUBKSyCFg4MV816GHjQZkPHDnFql7gE/T0eqE hKZ9j3dX2WbkQnOue66y4xYuR7kWTQl9VJdtmbrAd4lhZ3WjY5UetxQKo4j6RvzkMf/F +W/uUpdiEgRE7hXuA8QSOU1qDvQwkw+ZjTU7AKUjAzAsoZF7QwSD62EFzokuGkgZ8wYA GM5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=xSH0RWQ0Sc5pYUS471PVPmWO761Qjyq9ND9fXOyzgHc=; b=udCQW0hvZ6dOkY12Q4Ufuwk4/AzdK7jAxSDyvoVHTt9Hy7hEFAq41YfwBBoNOV+mXS icTNuJZ6pFVQ8+22DCvieXSEYvkN27tOVIgU5DbUK4ORQDcWB9FWdSWCkuNTUCXIuo4Q 0tjpeZCg83PC2WJhzm+t0fnhJElSruDqeV7edyVwSXXPLegUvpRMqN0lmmNStQLdNBdr Kai1Z6iylIBleihqbQSavzxXjSAvGza7AbfWSfENoXi1FkkhmkpbYZbFKJuFaXyPt1b/ fiJF/i621aXw7jveZLCrJ4WRLRDS03PMspWF2lzvG1YPzVE11jHu68/3BqQACasn5YGB 5NAw== X-Gm-Message-State: AIkVDXI/FhOg1vlyx6bMM/4nYzAHqW2mdby/cLEhZjdWICpuUan3TJkvaADiVGEmTyIPpg== X-Received: by 10.84.233.193 with SMTP id m1mr32897862pln.126.1484346474334; Fri, 13 Jan 2017 14:27:54 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id x8sm31655517pge.15.2017.01.13.14.27.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 Jan 2017 14:27:53 -0800 (PST) Subject: Re: powerpc.LINT* broken in netmap(4) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_37801E61-DF34-4A8A-ACD3-5B34951F261D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Fri, 13 Jan 2017 14:27:52 -0800 Cc: FreeBSD CURRENT , Luigi Rizzo Message-Id: <49F36EE5-D3BD-420A-9F16-2219C7C83AC8@gmail.com> References: To: freebsd-net@FreeBSD.org X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Fri, 13 Jan 2017 22:34:11 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:27:55 -0000 --Apple-Mail=_37801E61-DF34-4A8A-ACD3-5B34951F261D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 13, 2017, at 02:22, Ngie Cooper (yaneurabeya) = wrote: >=20 > Hi, > I spotted these compilation errors on universe12a.freebsd.org = for both powerpc.LINT and powerpc.LINT64: >=20 > cc1: warnings being treated as errors > /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function = 'generic_set_tx_event': > /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: = the address of 'generic_mbuf_destructor' will always evaluate as 'true' = [-Waddress] > --- netmap_generic.o --- > *** [netmap_generic.o] Error code 1 >=20 > I haven=E2=80=99t yet dug into why this only surfaces on = powerpc, yet=E2=80=A6 (CC -powerpc; BCC +powerpc) Hi, sparc64 has the same issue as powerpc*, so I suspect that gcc is = flagging this as an issue. Thanks, -Ngie PS. Sidenote: why was the SET_MBUF_DESTRUCTOR macro added, but not used = in nm_os_get_mbuf ? --Apple-Mail=_37801E61-DF34-4A8A-ACD3-5B34951F261D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYeVRoAAoJEPWDqSZpMIYVzf0QAMZ0TfNkcUpB+9Lksy3BNTSO tZZnO3gI8VpZ+XIBf/tlaoW7sKkwzVtficd1kvqz8iy4HCfapYU5Mf9BjowrQzY+ kPpUE+kckOwIYjS5AkQQHeEHKsr4F99O9Orj7DZBBWP4+9yeqDl48tnNw0N82zFF 4F3FDs9I/tFLyXNOX6K1gs4cJfUah1PwktFFIAXLXpAiqHx+TyxEgGFn0TJKmsVD TcKpW50MNFlc2lJzxKZeVVXCt2GwdjeautkKX+qVt+kbno4J+uJN0lTsJPBp25Tg M3rmgK8bBl7DL0DfreTwsVyQP4Czy9L0FwKkS8AkjPjLa0PZXDUsHJaeR9ITaAFD Tyyh44oIxcTashT20Yp590A0E0EOhuIkt18aEOAKgVuS8KKLl0GnsNsdxv1BtfSD 5H/PSjV7RdfijrzuDH9ChAs/7Z4GeL9MsBQIoNGz3lZ6dRRYq+b5WyPLTsf/ldpI mLm1bNyMuxPoYO+U7lYfK98qQS5fHKn6pO9vzdP4qu6qRfgx19VzfAC3hvzFNPrr tDeF13L8t5J5549rIXVyMEEUvSCQFiDqhwNrN5LIZBVzY3YP23tKM4WqaufAwLTC VctYhfTOCYxv74euyH39iGhW+4ohBtteJ6cV4QVf9DGFZ0+r3jR66vCbB10hBqRW 3845E6ngPZ0o1aGJbpck =8BD3 -----END PGP SIGNATURE----- --Apple-Mail=_37801E61-DF34-4A8A-ACD3-5B34951F261D--