From owner-freebsd-toolchain@freebsd.org Sun Jan 8 00:28:57 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 479A4C95E86 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 EA05C1360 for ; Sun, 8 Jan 2017 00:28:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24642 invoked from network); 8 Jan 2017 00:28:49 -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:28:49 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-toolchain@freebsd.org Sun Jan 8 04:03:51 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EB21CA5840 for ; Sun, 8 Jan 2017 04:03:51 +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 060D51864 for ; Sun, 8 Jan 2017 04:03:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10590 invoked from network); 8 Jan 2017 04:03:48 -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:03:48 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-toolchain@freebsd.org Sun Jan 8 09:05:45 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-toolchain@freebsd.org Sun Jan 8 10:24:21 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 150C7CA2B49 for ; Sun, 8 Jan 2017 10:24:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA73D111C for ; Sun, 8 Jan 2017 10:24:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14502 invoked from network); 8 Jan 2017 10:25: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:25: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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-toolchain@freebsd.org Sun Jan 8 10:57:14 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C65C7CA5197 for ; Sun, 8 Jan 2017 10:57:14 +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 870151B9A for ; Sun, 8 Jan 2017 10:57:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24472 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-toolchain@freebsd.org Sun Jan 8 14:44:04 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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-toolchain@freebsd.org Sun Jan 8 17:29:47 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EE4BCA5DA7 for ; Sun, 8 Jan 2017 17:29:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2C2215B3 for ; Sun, 8 Jan 2017 17:29:46 +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 v08HTkSJ016832 for ; Sun, 8 Jan 2017 17:29:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031 Date: Sun, 08 Jan 2017 17:29:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: shawn.webb@hardenedbsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 17:29:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214971 --- Comment #2 from Shawn Webb --- Ping. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 9 00:23:18 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45B90CA357C for ; Mon, 9 Jan 2017 00:23:18 +0000 (UTC) (envelope-from admin@x7.save85off.com) Received: from x7.save85off.com (x7.save85off.com [43.240.238.7]) by mx1.freebsd.org (Postfix) with ESMTP id EA0CC1B00 for ; Mon, 9 Jan 2017 00:23:17 +0000 (UTC) (envelope-from admin@x7.save85off.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=save85off; d=x7.save85off.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin@x7.save85off.com; bh=N+/Tww0hs683Nb5AMqPLmTbjiJU=; b=jbaQe0BOX4eJ7xctaOyyPrvrSqncSIaXSauSX4Lt0AuVKoMNU7t/GPGRQVY9y8ZZIwB9Y6/COKNA M054We/Nb/zjbToJAhuh2bax+hnPqOXx38EwkyV3jBFvqsBpvoyMiXeVQf30sLIcBvAITijVCLf4 HIIPpzJ6kE+jOvSBqbw= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=save85off; d=x7.save85off.com; b=h9RussClED0/AOrXDicFndJ33GdFiivJXIWEw/2Sn6N+OjIQXjmKrCkemIOzKOIqEUDMchnJVLxp kYqiexqCGS5C7XHqozhAL7ENBUANEEZ4P4pF0DoaN4CySzXGXPvvt9Gw+81iFPOXChbv21ww6z8M CfX3vJeF6LJZFW2w7TM=; From: "UGG Australia Boots" To: freebsd-toolchain@freebsd.org Date: 9 Jan 2017 08:12:59 +0800 Subject: Perfect New Year gifts in Free Over 100$ win 95$ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 00:23:18 -0000 From owner-freebsd-toolchain@freebsd.org Mon Jan 9 00:40:13 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CE25CA28E5 for ; Mon, 9 Jan 2017 00:40:13 +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 3C44A1DFE for ; Mon, 9 Jan 2017 00:40:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25182 invoked from network); 9 Jan 2017 00:41:29 -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:41:29 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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-toolchain@freebsd.org Mon Jan 9 01:52:40 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2B99CA5809 for ; Mon, 9 Jan 2017 01:52:40 +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 CE7401A8F for ; Mon, 9 Jan 2017 01:52:40 +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 v091qeES098764 for ; Mon, 9 Jan 2017 01:52:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215821] head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes Date: Mon, 09 Jan 2017 01:52:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 01:52:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215821 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |DUPLICATE --- Comment #2 from Mark Millard --- I mis-atttributed the cause of the address that the PowerMac G5 so-called "Quad Core" showed for the bootstrapped binutils context this report was about. That lead to other bad inferences. It turns out that bugzilla 215819's issue controls the behavior of this as well. So I'm closing this one as a poorly attributed report that is actually a duplicate of 215819 technically. *** This bug has been marked as a duplicate of bug 215819 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 9 01:52:41 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 175E7CA580C for ; Mon, 9 Jan 2017 01:52:41 +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 065FE1A90 for ; Mon, 9 Jan 2017 01:52:41 +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 v091qeEU098764 for ; Mon, 9 Jan 2017 01:52:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Mon, 09 Jan 2017 01:52:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 01:52:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 --- Comment #5 from Mark Millard --- *** Bug 215821 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 9 05:34:43 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C84ABCA51D1 for ; Mon, 9 Jan 2017 05:34:43 +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 69ED715AE for ; Mon, 9 Jan 2017 05:34:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22165 invoked from network); 9 Jan 2017 05:36:05 -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:36:05 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 05:34:43 -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-toolchain@freebsd.org Mon Jan 9 05:41:48 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85FEDCA5417 for ; Mon, 9 Jan 2017 05:41:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 749AC18F8 for ; Mon, 9 Jan 2017 05:41:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v095fmIM028829 for ; Mon, 9 Jan 2017 05:41:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [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 Date: Mon, 09 Jan 2017 05:41:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 05:41:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214855 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #0) [Still true at -r311147 .] I'll note that the abort happens at: if (off >=3D (bfd_vma) -2) abort (); in the code for: case R_PPC64_GOT16: case R_PPC64_GOT16_LO: case R_PPC64_GOT16_HI: case R_PPC64_GOT16_HA: case R_PPC64_GOT16_DS: case R_PPC64_GOT16_LO_DS: dogot: in: static bfd_boolean ppc64_elf_relocate_section (bfd *output_bfd, struct bfd_link_info *info, bfd *input_bfd, asection *input_section, bfd_byte *contents, Elf_Internal_Rela *relocs, Elf_Internal_Sym *local_syms, asection **local_sections) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 9 16:02:38 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 320E7CA7E7F for ; Mon, 9 Jan 2017 16:02: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 204FA1E59 for ; Mon, 9 Jan 2017 16:02: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 v09G2baI005722 for ; Mon, 9 Jan 2017 16:02:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents Date: Mon, 09 Jan 2017 16:02:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 16:02:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhibbits@FreeBSD.org --- Comment #1 from Justin Hibbits --- The naked 'r*' and 'f*' register designations are a Darwinism. SysV notati= on requires '%r*' and '%f*', or naked numbers. This should probably be filed upstream as well. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jan 9 21:44:02 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99AEFCA89E7 for ; Mon, 9 Jan 2017 21:44:02 +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 884241E0A for ; Mon, 9 Jan 2017 21:44:02 +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 v09Li2rQ091652 for ; Mon, 9 Jan 2017 21:44:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents Date: Mon, 09 Jan 2017 21:44:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:44:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215039 --- Comment #2 from Mark Millard --- (In reply to Justin Hibbits from comment #1) I have submitted llvm 31590 for the UnwindRegisters*.S related syntax error reports. (Not covering libunwind.cpp's static assert failure.) While I placed it against llvm's/clang's powerpc support initially my guess is they may reclassify it as against libunwind's source. (I did not find where to classify something as a libunwind issue and I also took the point of view that their compiler infrastructure was supposed to be able to parse their project's source code.) Of course they might end up declaring that llvm/projects/libunwind/ is intentionally darwin-specific for powerpc64 and powerpc and so only is expected to compile for a darwin target relative to what they support. (I've no clue of their policy/intent for such.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 10 09:06:36 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 241F8CA60B8 for ; Tue, 10 Jan 2017 09:06: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 12E4C1696 for ; Tue, 10 Jan 2017 09:06: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 v0A96ZCG070034 for ; Tue, 10 Jan 2017 09:06:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Tue, 10 Jan 2017 09:06:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:06:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 --- Comment #6 from Mark Millard --- Created attachment 178691 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178691&action= =3Dedit Have TOC_REF(...) in instructions use @toc notation for clang Have TOC_REF(...) in instructions use @toc notation for clang 3.9.1 so that clang does the right thing. The one old use of TOC_REF in TOC_ENTRY does not get the @toc notation use also have a TOC_NAME_FOR_REF(...) that does not get the @toc notation. TOC_REF(...) in turn uses TOC_NAME_FOR_REF(...) . --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 10 09:23:43 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CDA0CA67EF for ; Tue, 10 Jan 2017 09:23:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BAAD1E51 for ; Tue, 10 Jan 2017 09:23:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0A9Nh4w060956 for ; Tue, 10 Jan 2017 09:23:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215107] head -r309656 clang 3.9.0 for TARGET_ARCH=powerpc: -mminimal-toc rejected (missing llvm 19098 fix?) Date: Tue, 10 Jan 2017 09:23:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:23:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215107 --- Comment #6 from Mark Millard --- Created attachment 178693 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178693&action= =3Dedit Corrected patch to track compiler type Since at least gcc 4.2.1 requires the -mminimal-toc usage have the patch track the COMPILER_TYPE (gcc vs. not) for if -mminimal-toc is used vs. not. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 10 20:33:21 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA0DDCAAA69 for ; Tue, 10 Jan 2017 20:33:21 +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 C92791D76 for ; Tue, 10 Jan 2017 20:33:21 +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 v0AKXLCI095786 for ; Tue, 10 Jan 2017 20:33:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215107] head -r309656 clang 3.9.0 for TARGET_ARCH=powerpc: -mminimal-toc rejected (missing llvm 19098 fix?) Date: Tue, 10 Jan 2017 20:33:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 20:33:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215107 --- Comment #7 from Mark Millard --- Comment on attachment 178693 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178693 Corrected patch to track compiler type An alternate if supported in the context is: CFLAGS.gcc+=3D-mminimal-toc --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Jan 10 21:19:14 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFA64CAA5CD for ; Tue, 10 Jan 2017 21:19:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 72E6D1518 for ; Tue, 10 Jan 2017 21:19:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20850 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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-toolchain@freebsd.org Wed Jan 11 02:21:05 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2919ECAA26F for ; Wed, 11 Jan 2017 02:21: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 17C0E134F for ; Wed, 11 Jan 2017 02:21: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 v0B2L4kJ067609 for ; Wed, 11 Jan 2017 02:21:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215819] head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc Date: Wed, 11 Jan 2017 02:21:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhibbits@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component bug_status assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:21:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- Component|bin |kern Status|New |In Progress Assignee|freebsd-toolchain@FreeBSD.o |jhibbits@FreeBSD.org |rg | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 11 02:26:19 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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-toolchain@freebsd.org Wed Jan 11 04:04:27 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 779B6CAA514 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 1CEBE1889 for ; Wed, 11 Jan 2017 04:04:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 324 invoked from network); 11 Jan 2017 04:04:20 -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:20 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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-toolchain@freebsd.org Wed Jan 11 09:15:41 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBE96CAA4AB for ; Wed, 11 Jan 2017 09:15:41 +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 A202216F2 for ; Wed, 11 Jan 2017 09:15:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29048 invoked from network); 11 Jan 2017 09:16:03 -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:16:03 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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-toolchain@freebsd.org Wed Jan 11 16:08:06 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB744CAB89F for ; Wed, 11 Jan 2017 16:08:06 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 A5F19191F for ; Wed, 11 Jan 2017 16:08:06 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x229.google.com with SMTP id x2so116766295itf.1 for ; Wed, 11 Jan 2017 08:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BeBFr46zGIdy4a27ChdOoC41ZRVEcNB+ZQ1cqOa2KbI=; b=IXzAC736QIR0behYzwNUUEInZidJ0jh2P3Ah3ESzyvDjJWnuXVZXqzg40U25i5T2s1 1uOLaHzMC9vW5TanR9dKuU90lM35e80eUEejgz1lIQjje1gB5y7ewWGUf9rsAFgOGRNx jFbUBcmFSGl7jx/h2k4I5sMVd0NxUaeR7O2yKtL53ZA5ss/grhQRBnjq0hbVLdRhv6ty PAhmt9fnTAsZ01/Kv2aD3GjkQGemb8YbBc/xLgRwg/nnbHqZDF7PQgIgILXeZ8H7BNM4 tF3vpojY7uVrwBQylN1GPnBSBmKxg6jXxyPGtf1j4zoCiA9bXsR3yN0UrCq9ed4LuPFW q+FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BeBFr46zGIdy4a27ChdOoC41ZRVEcNB+ZQ1cqOa2KbI=; b=Z77AsQ3nP4P0leRm+rgoNKprLsMrXTzSSJLv5rjJwGs3qNEBRZhIHZTx/IO1NCr/By R1U7yAiOIiSzUlqWVoRUYpqyYC4iJbdy85gcBv7rNm0w4bR7aQhuKv7KXS1QSsNl7uO0 kaKYgl4rBuFKpyerp8qIynHMr29ZWx3dv3PdZNeK1xB3FsX7f0y9c8BrgXuD+yomP8aC NbLR+iWoeawppcmMJam2MASdFkV88JLd2aQ3XNkiXaopEjtekGWrqT9ovLco9mCjP56y S+rvg9rFQfzyewT74HpvtkrgpL5fixeyemZ8K4FgfWOohmVB+wIMgynSSynCJqp2Hi3w 8P2A== X-Gm-Message-State: AIkVDXKU+XEtBtiHHVawaDVaZiqUStR/2wlAd2PPYlwisyn0GdD04MbcHm7xqOkwH/MBFO1J87DCy0aa9K5e6Q== X-Received: by 10.36.212.66 with SMTP id x63mr8147905itg.14.1484150885899; Wed, 11 Jan 2017 08:08:05 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.175.159 with HTTP; Wed, 11 Jan 2017 08:07:45 -0800 (PST) In-Reply-To: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> From: Ed Maste Date: Wed, 11 Jan 2017 11:07:45 -0500 X-Google-Sender-Auth: y7YIPs5_4VIHFC5rbricWoWPZ5g Message-ID: Subject: Re: /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 To: Mark Millard Cc: FreeBSD Toolchain Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:08:07 -0000 On 11 January 2017 at 04:15, Mark Millard wrote: > > # ./a.out > ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 > Abort trap (core dumped) Would you paste the output of `readelf -r a.out`? From owner-freebsd-toolchain@freebsd.org Wed Jan 11 16:33:12 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5C23CABFD6 for ; Wed, 11 Jan 2017 16:33:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B584B19D7 for ; Wed, 11 Jan 2017 16:33:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0BGXCLc067227 for ; Wed, 11 Jan 2017 16:33:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215975] ThreadSanitizer lacks runtime in base Date: Wed, 11 Jan 2017 16:33:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:33:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215975 Bug ID: 215975 Summary: ThreadSanitizer lacks runtime in base Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org Flags: mfc-stable11? $ pkg install -qy llvm39 $ echo 'int main() {}' >a.c $ clang39 -fsanitize=3Dthread a.c $ cc -fsanitize=3Dthread a.c /usr/bin/ld: /usr/bin/../lib/clang/3.9.0/lib/freebsd/libclang_rt.tsan-x86_6= 4.a: No such file: No such file or directory cc: error: linker command failed with exit code 1 (use -v to see invocation) $ pkg info -xl llvm39 | fgrep tsan /usr/local/llvm39/include/sanitizer/tsan_interface_atomic.h /usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan-x86_= 64.a =20=20=20=20=20=20=20 /usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan-x86_64.a.syms =20=20=20=20=20=20=20 /usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan_cxx-x86_64.a =20=20=20=20=20=20=20 /usr/local/llvm39/lib/clang/3.9.1/lib/freebsd/libclang_rt.tsan_cxx-x86_64.a= .syms --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 11 16:44:20 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28526CAA754; Wed, 11 Jan 2017 16:44:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 E6B841FA2; Wed, 11 Jan 2017 16:44:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x234.google.com with SMTP id j18so87538653ioe.2; Wed, 11 Jan 2017 08:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uIINW97QGZZhD66LonNssQqT6G00epZuHlD2tvStVWc=; b=k+ReWa3q4MZPFVoXrCmUgcgr7jcMwV3PeBV7JzgeORlLdI7u5OLLqRBnzk6Ch+kAW9 hf7dwsVEFDsY1R/TN1yaj1bjiNopVZyP9RmdF8dJhzSOipHx7sqXxQu/rqQSRicsmn4w iWzrDIsE8s3AzdLXo4o0o8CbBpG5CM1opAbxL+b+cyJ9D5Ti6NHE5FOTYaHHonwZ05Mg ICVdLfEe1f/cl8Q9Ekm4bOTQdx0shqaxuhhXhEo3hrqz3kEJtjrufxlogKF4mKOfxiLD 3dESS83DCx+xQ33YzHPEBR7noKSMuc5gdMdWA7wdgb88Xi5YKwgWYrAPSpILe7vQ8/0q BBuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uIINW97QGZZhD66LonNssQqT6G00epZuHlD2tvStVWc=; b=i8iUEpXVF6ldwI+XuJ43qHq0a6V2DyQzQdJq3eJsnGJ7zbCRkZVuqf7U6doz1VugZs q7CEgCmjig+hwoCeQCLwtbE0xdlGFgxoT7mXORkFTVaA3padFMUtwyKwTal8JY0JyTdG Tz4iKRMF2lBGhBbz4f/VQnN+isO9QxcsWrc2/i6dcIQHNfdQeP0xlxDgEtMYQs6ljNTQ etsnXOe/NWI8yOpiHiU8fjYVxd8gFBprI+6IB1T8dooshxDJd4Mn7B6piDD1esr+AczN +7wGn60sN+KSyYPaa0GPpU+G/HHBDBlcu7X1NuZZdQvu3Aa3VykM7xHaaQ3fZFoZpngo ut7Q== X-Gm-Message-State: AIkVDXIuBVhVKXR4kZ6ONhJ8xGRpnQfpBJaZfeFGAVESxM27o1avH/2TRcbrUQGl8VHB6ErbpAktd2JOfWHtDw== X-Received: by 10.107.142.84 with SMTP id q81mr8560508iod.169.1484153059296; Wed, 11 Jan 2017 08:44:19 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.175.159 with HTTP; Wed, 11 Jan 2017 08:43:58 -0800 (PST) In-Reply-To: References: From: Ed Maste Date: Wed, 11 Jan 2017 11:43:58 -0500 X-Google-Sender-Auth: erpqm1pLbYd0_BnGXPpz-hPRRsA Message-ID: Subject: Re: clang on armv6 incorrectly emits call to sincos() To: Jia-Shiun Li Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:44:20 -0000 On 11 January 2017 at 09:42, Jia-Shiun Li wrote: > > Think this optimization should be turned off for armv6 from base > clang/llvm, instead of patching individual ports or ports infrastructure. You're right that this needs to be fixed in the compiler or the base system, not individual ports. LLVM has a hasSinCos() and should not be emitting the sincos libcall on platforms that do not have it. Would you care to submit a PR for this? -Ed From owner-freebsd-toolchain@freebsd.org Wed Jan 11 17:32:05 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3DECCAB2A0; Wed, 11 Jan 2017 17:32:04 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEFAC1475; Wed, 11 Jan 2017 17:32:04 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id l7so153016960qtd.1; Wed, 11 Jan 2017 09:32:04 -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=KReHlXxE/ZxPTRsoKR2G8aDMKaXjK/fWvR3p8coTmGY=; b=WIysKApytifK7SnMfO0Ny3hcm8IKEwKRtSdnRJT5VXXOcnjMeA4FmHDjU1gmc6sMu7 pwX9TMJxVMpx97rpDaeYWHqdUNEGvdeNGjgjqz+96a8d9Ij1uqh+Rv+afH4XfdtqazGE PUGTHZYvttBszouYC1cKXuz0lIAfTZNs3+0E9CD4VEO6MLrqiVlM0vEnvMLk61FuYpYz s/yJiL2O7GDmdFeoVrU9TL1lDzlK4weSwNB2TW+KXGb1C5cBJpP9BZVbn8hNQe0dvU3F Oo6jwUv1sLDem0+jF1NqVJp2I67OxTB9c0ITw+aYuffL0aw8F7o0PIfco4s1nLLS+CCm XzNg== 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=KReHlXxE/ZxPTRsoKR2G8aDMKaXjK/fWvR3p8coTmGY=; b=S+/zn+OERSVvEWm4y9KDj2Iklpul5NyLNZ/OQYBLMpYrJETEue6Y39rXgu2+eoBRa8 S02CNWQly5sWpd8t+QuHLngmoFNIp+SroJDeuh13MxYIWRwQ/hNvRgrE2xqKLZwGFVdT Vf87jlIYYXk9u1uWCQWS/ILa8HWFWExbYugqDDiw2rwV0bVVbcUHwMJYQErL7xEIG8Jt 9cD5rkxmw3knbLhX/LV/fBrPH5S+ofWmmuz120Rd3bnjrj/qzTyS6g04bKEZNHZjIsdB 8+RdkBRysj1Ckpwwc6UjLOtr9sNTZg+M46hsIPtSD75pzy+n+A/Knw6HNWhAQvfczbEx XeCQ== X-Gm-Message-State: AIkVDXKr+7gnxDWLV3gvTLFwPwzRoLT8nOpg4oCH87aJ2Ej5inULo21XWHkmC3sJP3gRQxZdxo/Qssnhn2gnJg== X-Received: by 10.237.53.201 with SMTP id d9mr3779116qte.235.1484155923608; Wed, 11 Jan 2017 09:32:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.82.149 with HTTP; Wed, 11 Jan 2017 09:31:33 -0800 (PST) In-Reply-To: References: From: Jia-Shiun Li Date: Thu, 12 Jan 2017 01:31:33 +0800 Message-ID: Subject: Re: clang on armv6 incorrectly emits call to sincos() To: Ed Maste Cc: "freebsd-arm@freebsd.org" , "freebsd-toolchain@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:32:05 -0000 On Thu, Jan 12, 2017 at 12:43 AM, Ed Maste wrote: > You're right that this needs to be fixed in the compiler or the base > system, not individual ports. LLVM has a hasSinCos() and should not be > emitting the sincos libcall on platforms that do not have it. Would > you care to submit a PR for this? > > Roger. Create bug #215977. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215977 -Jia-Shiun. From owner-freebsd-toolchain@freebsd.org Wed Jan 11 17:47:42 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51243CABB08 for ; Wed, 11 Jan 2017 17:47:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0542B1008 for ; Wed, 11 Jan 2017 17:47:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24740 invoked from network); 11 Jan 2017 17:47:35 -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 17:47:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 11 Jan 2017 12:47:35 -0500 (EST) Received: (qmail 1751 invoked from network); 11 Jan 2017 17:47:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jan 2017 17:47:35 -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 E7EACEC9055; Wed, 11 Jan 2017 09:47:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: /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 From: Mark Millard In-Reply-To: Date: Wed, 11 Jan 2017 09:47:34 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:47:42 -0000 On 2017-Jan-11, at 8:07 AM, Ed Maste wrote: > On 11 January 2017 at 04:15, Mark Millard = wrote: >>=20 >> # ./a.out >> ld-elf.so.1: assert failed: = /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 >> Abort trap (core dumped) >=20 > Would you paste the output of `readelf -r a.out`? Here you go, for ld.lld and for ld.bfd . . . For -fuse-ld=3Dlld : # readelf -r a.out Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + = r_addend 000010030038 000300000014 0000000000000000 atexit + = 0 000010030040 000200000014 0000000000000000 _init_tls = + 0 000010030048 000500000014 0000000000000000 exit + 0 For -fuse-ld=3Dbfd : # readelf -r a.out Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + = r_addend 000010010cb8 000300000015 0000000000000000 atexit + = 0 000010010cd0 000400000015 0000000000000000 _init_tls = + 0 000010010ce8 000600000015 0000000000000000 exit + 0 These were done on the powerpc64 machine (native). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Jan 11 18:33:05 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF3D7CAB7FD for ; Wed, 11 Jan 2017 18:33: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 AEB0819FF for ; Wed, 11 Jan 2017 18:33: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 v0BIX5st044164 for ; Wed, 11 Jan 2017 18:33:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215798] clang: please Include thread sanitizer (and all other available sanitizers) Date: Wed, 11 Jan 2017 18:33:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 18:33:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215798 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jbeich@FreeBSD.org --- Comment #2 from Dimitry Andric --- *** Bug 215975 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 11 18:33:05 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75A0ECAB7FB for ; Wed, 11 Jan 2017 18:33: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 64E5B19FD for ; Wed, 11 Jan 2017 18:33: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 v0BIX5sp044164 for ; Wed, 11 Jan 2017 18:33:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215975] ThreadSanitizer lacks runtime in base Date: Wed, 11 Jan 2017 18:33:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 18:33:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215975 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |dim@FreeBSD.org Resolution|--- |DUPLICATE --- Comment #1 from Dimitry Andric --- Same as bug 215798: ThreadSanitizer does not work on FreeBSD, unfortunately. Somebody needs to do the work to get it functional. *** This bug has been marked as a duplicate of bug 215798 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jan 11 19:51:20 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62E15CAB9A0 for ; Wed, 11 Jan 2017 19:51:20 +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 2AACB15B0; Wed, 11 Jan 2017 19:51:19 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 4547412CB9F; Wed, 11 Jan 2017 20:48:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484164124; bh=bdbTvatiYlUH1uv41TCfIAYixFtSemR+za9NJPPChcc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gsViBZNjg3Ske/jDAiB7utVjxT5PsAIU2A7fCYy8es6yrhu01quSHA/5BEkeX2mO3 bMckSu8c7xFw4eFULCpzikN9sv070tcwu7ZCJyaEsRTaxMrj02XexisMSzBYJPegNh EVcAhzoecBlRkJb3pNaBbwmlgiCfTn65nJW+uo2Y= Date: Wed, 11 Jan 2017 20:48:44 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain Subject: Re: /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: <20170111194844.GA16135@vlakno.cz> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:51:20 -0000 Can you try this patch? Index: tools/lld/ELF/Target.cpp =================================================================== --- tools/lld/ELF/Target.cpp (revision 291691) +++ tools/lld/ELF/Target.cpp (working copy) @@ -1062,7 +1062,8 @@ } PPC64TargetInfo::PPC64TargetInfo() { - PltRel = GotRel = R_PPC64_GLOB_DAT; + GotRel = R_PPC64_GLOB_DAT; + PltRel = R_PPC64_JMP_SLOT; RelativeRel = R_PPC64_RELATIVE; GotEntrySize = 8; GotPltEntrySize = 8; On Wed, Jan 11, 2017 at 09:47:34AM -0800, Mark Millard wrote: > > On 2017-Jan-11, at 8:07 AM, Ed Maste wrote: > > > On 11 January 2017 at 04:15, Mark Millard wrote: > >> > >> # ./a.out > >> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 > >> Abort trap (core dumped) > > > > Would you paste the output of `readelf -r a.out`? > > Here you go, for ld.lld and for ld.bfd . . . > > For -fuse-ld=lld : > > # readelf -r a.out > > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name + r_addend > 000010030038 000300000014 0000000000000000 atexit + 0 > 000010030040 000200000014 0000000000000000 _init_tls + 0 > 000010030048 000500000014 0000000000000000 exit + 0 > > For -fuse-ld=bfd : > > # readelf -r a.out > > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name + r_addend > 000010010cb8 000300000015 0000000000000000 atexit + 0 > 000010010cd0 000400000015 0000000000000000 _init_tls + 0 > 000010010ce8 000600000015 0000000000000000 exit + 0 > > These were done on the powerpc64 machine (native). > > > === > Mark Millard > markmi at dsl-only.net > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Wed Jan 11 20:37:56 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 405E0CAB261 for ; Wed, 11 Jan 2017 20:37:56 +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 E6BC91AD0 for ; Wed, 11 Jan 2017 20:37:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19167 invoked from network); 11 Jan 2017 20:37:54 -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 20:37:54 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 11 Jan 2017 15:37:54 -0500 (EST) Received: (qmail 7300 invoked from network); 11 Jan 2017 20:37:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jan 2017 20:37:54 -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 604ADEC8F7B; Wed, 11 Jan 2017 12:37:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: /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 From: Mark Millard In-Reply-To: <20170111194844.GA16135@vlakno.cz> Date: Wed, 11 Jan 2017 12:37:52 -0800 Cc: Ed Maste , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:37:56 -0000 On 2017-Jan-11, at 11:48 AM, Roman Divacky = wrote: > Can you try this patch? >=20 > Index: tools/lld/ELF/Target.cpp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- tools/lld/ELF/Target.cpp (revision 291691) > +++ tools/lld/ELF/Target.cpp (working copy) > @@ -1062,7 +1062,8 @@ > } >=20 > PPC64TargetInfo::PPC64TargetInfo() { > - PltRel =3D GotRel =3D R_PPC64_GLOB_DAT; > + GotRel =3D R_PPC64_GLOB_DAT; > + PltRel =3D R_PPC64_JMP_SLOT; > RelativeRel =3D R_PPC64_RELATIVE; > GotEntrySize =3D 8; > GotPltEntrySize =3D 8; The result for the generated a.out (via ld.lld) was: # /usr/local/bin/gdb a.out . . . Reading symbols from a.out...done. (gdb) run Starting program: /root/c_tests/a.out=20 Program received signal SIGSEGV, Segmentation fault. 0x000000001001056c in ?? () (gdb) bt #0 0x000000001001056c in ?? () #1 0x00000000100100d8 in ?? () #2 0x00000000500279e0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Backtrace stopped: frame did not save the PC =3D=3D=3D Mark Millard markmi at dsl-only.net On Wed, Jan 11, 2017 at 09:47:34AM -0800, Mark Millard wrote: >=20 > On 2017-Jan-11, at 8:07 AM, Ed Maste wrote: >=20 >> On 11 January 2017 at 04:15, Mark Millard = wrote: >>>=20 >>> # ./a.out >>> ld-elf.so.1: assert failed: = /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 >>> Abort trap (core dumped) >>=20 >> Would you paste the output of `readelf -r a.out`? >=20 > Here you go, for ld.lld and for ld.bfd . . . >=20 > For -fuse-ld=3Dlld : >=20 > # readelf -r a.out >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 000010030038 000300000014 0000000000000000 atexit = + 0 > 000010030040 000200000014 0000000000000000 = _init_tls + 0 > 000010030048 000500000014 0000000000000000 exit + = 0 >=20 > For -fuse-ld=3Dbfd : >=20 > # readelf -r a.out >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 000010010cb8 000300000015 0000000000000000 atexit = + 0 > 000010010cd0 000400000015 0000000000000000 = _init_tls + 0 > 000010010ce8 000600000015 0000000000000000 exit + = 0 >=20 > These were done on the powerpc64 machine (native). >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Wed Jan 11 21:09:29 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5EA9CAA21E for ; Wed, 11 Jan 2017 21:09:29 +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 3AA5C1C1D for ; Wed, 11 Jan 2017 21:09:28 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 6BADF12CD47; Wed, 11 Jan 2017 22:06:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484168818; bh=BNNUEc2nP5p+WokX1WJ2koRTgCDe8dYX+iQiqQ+h8ls=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=bDFba2tz6M5C4dmVGnPJ9CQ8uNsny/vStkdeX1wndIGNOcD7y4DUjWAsyFZSAS/Ch 0UDHQFytyrhTreu385yal8hFuKxO9OnB+rfeb/Az/Qxbny8aIEajeQTK8YBD6Feedq 2CUypwtZkzQvAq3KNDfxsgpiZKMc4SvZTeKy99RI= Date: Wed, 11 Jan 2017 22:06:58 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain Subject: Re: /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: <20170111210658.GA20265@vlakno.cz> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:09:29 -0000 Looks like a progress :) Three questions... Is the readelf -a reasonable now? If you compile with -g, does the backtrace make a bit more sense? And finally, can you try to "nexti/stepi" in gdb from _start to see where things go wrong? Possibly doing it both for ld linked a.out and lld linked a.out and compare where things differ. Thanks! Roman On Wed, Jan 11, 2017 at 12:37:52PM -0800, Mark Millard wrote: > On 2017-Jan-11, at 11:48 AM, Roman Divacky wrote: > > > Can you try this patch? > > > > Index: tools/lld/ELF/Target.cpp > > =================================================================== > > --- tools/lld/ELF/Target.cpp (revision 291691) > > +++ tools/lld/ELF/Target.cpp (working copy) > > @@ -1062,7 +1062,8 @@ > > } > > > > PPC64TargetInfo::PPC64TargetInfo() { > > - PltRel = GotRel = R_PPC64_GLOB_DAT; > > + GotRel = R_PPC64_GLOB_DAT; > > + PltRel = R_PPC64_JMP_SLOT; > > RelativeRel = R_PPC64_RELATIVE; > > GotEntrySize = 8; > > GotPltEntrySize = 8; > > The result for the generated a.out (via ld.lld) was: > > # /usr/local/bin/gdb a.out > . . . > Reading symbols from a.out...done. > (gdb) run > Starting program: /root/c_tests/a.out > > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () > (gdb) bt > #0 0x000000001001056c in ?? () > #1 0x00000000100100d8 in ?? () > #2 0x00000000500279e0 in ._rtld_start () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > Backtrace stopped: frame did not save the PC > > > === > Mark Millard > markmi at dsl-only.net > > > On Wed, Jan 11, 2017 at 09:47:34AM -0800, Mark Millard wrote: > > > > On 2017-Jan-11, at 8:07 AM, Ed Maste wrote: > > > >> On 11 January 2017 at 04:15, Mark Millard wrote: > >>> > >>> # ./a.out > >>> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 > >>> Abort trap (core dumped) > >> > >> Would you paste the output of `readelf -r a.out`? > > > > Here you go, for ld.lld and for ld.bfd . . . > > > > For -fuse-ld=lld : > > > > # readelf -r a.out > > > > Relocation section with addend (.rela.plt): > > r_offset r_info r_type st_value st_name + r_addend > > 000010030038 000300000014 0000000000000000 atexit + 0 > > 000010030040 000200000014 0000000000000000 _init_tls + 0 > > 000010030048 000500000014 0000000000000000 exit + 0 > > > > For -fuse-ld=bfd : > > > > # readelf -r a.out > > > > Relocation section with addend (.rela.plt): > > r_offset r_info r_type st_value st_name + r_addend > > 000010010cb8 000300000015 0000000000000000 atexit + 0 > > 000010010cd0 000400000015 0000000000000000 _init_tls + 0 > > 000010010ce8 000600000015 0000000000000000 exit + 0 > > > > These were done on the powerpc64 machine (native). > > > > > > === > > 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" From owner-freebsd-toolchain@freebsd.org Wed Jan 11 21:23:57 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BCC7CAAC48 for ; Wed, 11 Jan 2017 21:23:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 4EC1B195C for ; Wed, 11 Jan 2017 21:23:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x236.google.com with SMTP id l66so3686409ioi.1 for ; Wed, 11 Jan 2017 13:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QUttNBXBj/VkWExKezfqCkItLelf0yxe6FAnSckcBAc=; b=oMmxhvwxVDl0USn1tTD6w6pPKLdpzwjDfna1F2gFaNpF17zNBS5bihqYtbClWR/sC0 mhqHLd4XB+2ji8QoRGtXtitHgwCQbN+t2HpVILwhTq8ab7Ac3rvwP0rqonGmNMMjCDdR mivXCcx1Nd6QqfClaskPq5t7AmEgip6FhkcXRDfGtL74ePguJ6IToHif6voKjzNX5h+r s8YvGosjwSaE27HyPLf1nlZDc4NqRhc1wEEXrh30Mq2b08b8ni41+6t0LCZYSS+Rci78 +gEEoeZD3+B5cDWiKJZNs8tVITkdaDg3HioZlLRUXaY23Opis8/OVpRN04AS7okk9i4I VjEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QUttNBXBj/VkWExKezfqCkItLelf0yxe6FAnSckcBAc=; b=lE8tHi7gJIfxPvMn2hoSIM56Kpe+QHSKQbe+RoyPoz8xiSTu6qvxGlmT7fBmcIVRG2 amLD8TuiCGU5LNCBqiJRir01Flb+bA/ii1lZE6KEvT+71dT1UlUS+HxwIu1vVeCYyROZ 7AY387Dm7bjTbnmzfaLzEB7rtc4g8Xfm6BoBTYhH2ekYgBjnefehzklhtJ/Fc8TmeslD 0VIvXxinw5mb294VZ4lyh4Ik5jVzkMmYiaB8BZm7wRTcTTT2zllj9KEmBsPfnCXrfhJ9 J5H4mGOs+fFyd/evi2BEDrhaVgjBQgcMZzgJiQuaFPXmxXOKcY5dVmgyIaldEve04fse 7+Dg== X-Gm-Message-State: AIkVDXIlen0aNieHE1CktVUrykHajHHNHa2dn9OWeWIz/G9fCsdWua1kR4b41LJbwKX5U2fa4MLg1EQeXWy0xQ== X-Received: by 10.107.23.198 with SMTP id 189mr3772070iox.162.1484169836627; Wed, 11 Jan 2017 13:23:56 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.175.159 with HTTP; Wed, 11 Jan 2017 13:23:36 -0800 (PST) In-Reply-To: <20170111210658.GA20265@vlakno.cz> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> <20170111210658.GA20265@vlakno.cz> From: Ed Maste Date: Wed, 11 Jan 2017 21:23:36 +0000 X-Google-Sender-Auth: ykR-oqBCcxM4brJE9v0p9ge7mBw Message-ID: Subject: Re: /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 To: Roman Divacky Cc: Mark Millard , FreeBSD Toolchain Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:23:57 -0000 On 11 January 2017 at 21:06, Roman Divacky wrote: > Looks like a progress :) Three questions... > > Is the readelf -a reasonable now? FYI, I just committed an ELF Tool Chain fix (r311941) so readelf should display the relocation types properly now. > If you compile with -g, does the > backtrace make a bit more sense? And finally, can you try to "nexti/stepi" in gdb from > _start to see where things go wrong? Possibly doing it both for ld linked a.out > and lld linked a.out and compare where things differ. You can also build rtld with additional debugging by adding -DDEBUG to CFLAGS. In libexec/rtld-elf/Makefile there's an example command line for building it locally, but I've just added CFLAGS+=-DDEBUG to the Makefile in my test tree and built it along with the rest of my full cross build. From owner-freebsd-toolchain@freebsd.org Thu Jan 12 08:38:02 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2C33CAA8C5 for ; Thu, 12 Jan 2017 08:38:02 +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 A5F081B71 for ; Thu, 12 Jan 2017 08:38:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12335 invoked from network); 12 Jan 2017 08:37:55 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Jan 2017 08:37:55 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 12 Jan 2017 03:37:55 -0500 (EST) Received: (qmail 18205 invoked from network); 12 Jan 2017 08:37:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Jan 2017 08:37:55 -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 A9B4FEC7B76; Thu, 12 Jan 2017 00:37:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: /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 From: Mark Millard In-Reply-To: Date: Thu, 12 Jan 2017 00:37:53 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> <20170111210658.GA20265@vlakno.cz> To: Ed Maste , Roman Divacky X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 08:38:03 -0000 On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: > On 11 January 2017 at 21:06, Roman Divacky = wrote: >> Looks like a progress :) Three questions... >>=20 >> Is the readelf -a reasonable now? >=20 > FYI, I just committed an ELF Tool Chain fix (r311941) so readelf > should display the relocation types properly now. Thanks. I updated to -r311950 to pick this up. >> If you compile with -g, does the >> backtrace make a bit more sense? And finally, can you try to = "nexti/stepi" in gdb from >> _start to see where things go wrong? Possibly doing it both for ld = linked a.out >> and lld linked a.out and compare where things differ. I had compiled with -g. It never gets to main. . . # /usr/local/bin/gdb a.out . . . Reading symbols from a.out...done. (gdb) start Temporary breakpoint 1 at 0x1001045c: file main.c, line 3. Starting program: /root/c_tests/a.out=20 Program received signal SIGSEGV, Segmentation fault. 0x000000001001056c in ?? () Note that the temporary breakpoint is never hit. (gdb) bt #0 0x000000001001056c in ?? () #1 0x00000000100100d8 in ?? () #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Backtrace stopped: frame did not save the PC (gdb) up 2 #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ (gdb) disass Dump of assembler code for function ._rtld_start: 0x0000000050027930 <+0>: stdu r1,-144(r1) 0x0000000050027934 <+4>: std r3,96(r1) 0x0000000050027938 <+8>: std r4,104(r1) 0x000000005002793c <+12>: std r5,112(r1) 0x0000000050027940 <+16>: std r8,136(r1) 0x0000000050027944 <+20>: bl 0x50027950 <._rtld_start+32> 0x0000000050027948 <+24>: .long 0x0 0x000000005002794c <+28>: .long 0x30e40 0x0000000050027950 <+32>: mflr r3 0x0000000050027954 <+36>: ld r4,0(r3) 0x0000000050027958 <+40>: add r3,r4,r3 0x000000005002795c <+44>: ld r4,-32768(r2) 0x0000000050027960 <+48>: subf r4,r4,r2 0x0000000050027964 <+52>: bl 0x50027c64 0x0000000050027968 <+56>: nop 0x000000005002796c <+60>: ld r4,104(r1) 0x0000000050027970 <+64>: addi r3,r4,-8 0x0000000050027974 <+68>: addi r4,r1,128 0x0000000050027978 <+72>: addi r5,r1,120 0x000000005002797c <+76>: bl 0x50028608 <_rtld> 0x0000000050027980 <+80>: nop 0x0000000050027984 <+84>: ld r2,8(r3) 0x0000000050027988 <+88>: ld r11,16(r3) 0x000000005002798c <+92>: ld r3,0(r3) 0x0000000050027990 <+96>: mtlr r3 0x0000000050027994 <+100>: ld r3,96(r1) 0x0000000050027998 <+104>: ld r4,104(r1) 0x000000005002799c <+108>: ld r5,112(r1) 0x00000000500279a0 <+112>: ld r6,120(r1) 0x00000000500279a4 <+116>: ld r7,128(r1) 0x00000000500279a8 <+120>: ld r8,136(r1) 0x00000000500279ac <+124>: blrl =3D> 0x00000000500279b0 <+128>: li r0,1 0x00000000500279b4 <+132>: sc =20 0x00000000500279b8 <+136>: nop 0x00000000500279bc <+140>: nop End of assembler dump. So setting a breakpoint at 0x00000000500279ac and trying again: (gdb) run Starting program: /root/c_tests/a.out=20 Breakpoint 3, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ (gdb) info registers r0 0x50027980 1342339456 r1 0xffffffffffffdaf0 18446744073709542128 r2 0x10028138 268599608 r3 0x1 1 r4 0xffffffffffffdbb8 18446744073709542328 r5 0xffffffffffffdbc8 18446744073709542344 r6 0x5004c000 1342488576 r7 0x50058b30 1342540592 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x20000000 536870912 r13 0x50057010 1342533648 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0x0 0 r27 0x0 0 r28 0x0 0 r29 0x0 0 r30 0x0 0 r31 0x0 0 pc 0x500279ac 0x500279ac <._rtld_start+124> msr cr 0x22000c00 570428416 lr 0x10010000 0x10010000 ctr 0x50043a80 1342454400 xer 0x20000000 536870912 (gdb) stepi 0x0000000010010000 in ?? () and that is effectively at ._start . NOTE: There is no ._start name in the disassembly listed by objdump. By contrast for -fuse-ld=3Dbfd building a.out objdump shows: 0000000010000438 <._start> mflr r0 000000001000043c <._start+0x4> mfcr r12 0000000010000440 <._start+0x8> std r31,-8(r1) 0000000010000444 <._start+0xc> std r0,16(r1) 0000000010000448 <._start+0x10> stw r12,8(r1) 000000001000044c <._start+0x14> stdu r1,-176(r1) . . . In gdb for ld.lld used: Reading symbols from a.out...done. (gdb) br *0x00000000500279ac Breakpoint 1 at 0x500279ac (gdb) run Starting program: /root/c_tests/a.out=20 Breakpoint 1, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ (gdb) stepi 0x0000000010010000 in ?? () (gdb)=20 0x0000000010010004 in ?? () (gdb) display/i $pc 1: x/i $pc =3D> 0x10010004: mfcr r12 (gdb) stepi 0x0000000010010008 in ?? () 1: x/i $pc =3D> 0x10010008: std r31,-8(r1) (gdb)=20 0x000000001001000c in ?? () 1: x/i $pc =3D> 0x1001000c: std r0,16(r1) . . . (gdb)=20 0x00000000100100a0 in ?? () 1: x/i $pc =3D> 0x100100a0: beq 0x100100ac (gdb)=20 0x00000000100100ac in ?? () 1: x/i $pc =3D> 0x100100ac: cmpldi r8,0 (gdb)=20 0x00000000100100b0 in ?? () 1: x/i $pc =3D> 0x100100b0: beq 0x100100c0 (gdb)=20 0x00000000100100c0 in ?? () 1: x/i $pc =3D> 0x100100c0: addis r3,r2,0 (gdb)=20 0x00000000100100c4 in ?? () 1: x/i $pc =3D> 0x100100c4: ld r3,32552(r3) (gdb)=20 0x00000000100100c8 in ?? () 1: x/i $pc =3D> 0x100100c8: cmpldi r3,0 (gdb)=20 0x00000000100100cc in ?? () 1: x/i $pc =3D> 0x100100cc: beq 0x100100e0 (gdb)=20 0x00000000100100d0 in ?? () 1: x/i $pc =3D> 0x100100d0: mr r3,r7 (gdb)=20 0x00000000100100d4 in ?? () 1: x/i $pc =3D> 0x100100d4: bl 0x10010560 Note: Below is from plt : Disassembly of section .plt: 0000000010010560 <.plt> std r2,40(r1) 0000000010010564 <.plt+0x4> addis r11,r2,0 0000000010010568 <.plt+0x8> ld r12,32512(r11) 000000001001056c <.plt+0xc> ld r11,0(r12) <<<<<=3D=3D=3D=3D=3D = Fails here. 0000000010010570 <.plt+0x10> mtctr r11 0000000010010574 <.plt+0x14> ld r2,8(r12) 0000000010010578 <.plt+0x18> ld r11,16(r12) 000000001001057c <.plt+0x1c> bctr (By setting breakpoints in the 3 such .plt code blocks: this is the first .plt code block executed and it fails.) The .plt is different from what ld.bfd generates: no __glink_PLTresolve or its use and the code does not appear strictly equivalent to me. Back to gdb based information: (gdb) info registers r0 0x500279b0 1342339504 r1 0xffffffffffffda40 18446744073709541952 r2 0x10028138 268599608 r3 0x50058b30 1342540592 r4 0x0 0 r5 0xffffffffffffdbc8 18446744073709542344 r6 0x5004c000 1342488576 r7 0x50058b30 1342540592 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x22000c00 570428416 r13 0x50057010 1342533648 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x10028138 268599608 r26 0x0 0 r27 0x0 0 r28 0x1 1 r29 0xffffffffffffdbb8 18446744073709542328 r30 0xffffffffffffdbc8 18446744073709542344 r31 0xffffffffffffda40 18446744073709541952 pc 0x10010560 0x10010560 msr cr 0x42000c00 1107299328 lr 0x100100d8 0x100100d8 ctr 0x50043a80 1342454400 xer 0x20000000 536870912 (gdb)=20 0x0000000010010560 in ?? () 1: x/i $pc =3D> 0x10010560: std r2,40(r1) (gdb)=20 0x0000000010010564 in ?? () 1: x/i $pc =3D> 0x10010564: addis r11,r2,0 (gdb)=20 0x0000000010010568 in ?? () 1: x/i $pc =3D> 0x10010568: ld r12,32512(r11) (gdb)=20 0x000000001001056c in ?? () 1: x/i $pc =3D> 0x1001056c: ld r11,0(r12) (gdb)=20 Program received signal SIGSEGV, Segmentation fault. 0x000000001001056c in ?? () 1: x/i $pc =3D> 0x1001056c: ld r11,0(r12) The source code (from lib/csu/powerpc64/crt1.c ) is: void _start(int argc, char **argv, char **env, const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), struct ps_strings *ps_strings) { handle_argv(argc, argv, env); if (ps_strings !=3D (struct ps_strings *)0) __ps_strings =3D ps_strings; if (&_DYNAMIC !=3D NULL) atexit(cleanup); else _init_tls(); #ifdef GCRT atexit(_mcleanup); monstartup(&eprol, &etext); #endif handle_static_init(argc, argv, env); exit(main(argc, argv, env)); } The 3 plt code blocks are for: atexit _init_tls exit from what I can tell, possibly not in that order. Overall: The plt handling seems to be broken. > You can also build rtld with additional debugging by adding -DDEBUG to > CFLAGS. In libexec/rtld-elf/Makefile there's an example command line > for building it locally, but I've just added CFLAGS+=3D-DDEBUG to the > Makefile in my test tree and built it along with the rest of my full > cross build. # svnlite diff /usr/src/libexec/rtld-elf/Makefile Index: /usr/src/libexec/rtld-elf/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/libexec/rtld-elf/Makefile (revision 311950) +++ /usr/src/libexec/rtld-elf/Makefile (working copy) @@ -17,6 +17,7 @@ malloc.c xmalloc.c debug.c libmap.c MAN=3D rtld.1 CSTD?=3D gnu99 +CFLAGS+=3D-DDEBUG CFLAGS+=3D -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding CFLAGS+=3D -I${SRCTOP}/lib/csu/common .if exists(${.CURDIR}/${MACHINE_ARCH}) The above did not seem to make much of a difference for the code involved, likely because crt1.c is from lib/csu/powerpc64/ instead of from libexec/rtld-elf/ . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jan 12 10:49:53 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70862CACB68 for ; Thu, 12 Jan 2017 10:49:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 605E81CA1 for ; Thu, 12 Jan 2017 10:49:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0CAnrLP049491 for ; Thu, 12 Jan 2017 10:49:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215969] c++ compiler regression Date: Thu, 12 Jan 2017 10:49:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:49:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215969 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Jan 12 18:38:22 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D0CECAB3CA for ; Thu, 12 Jan 2017 18:38:22 +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 1CBEE1FAF for ; Thu, 12 Jan 2017 18:38:22 +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 v0CIcLJc065015 for ; Thu, 12 Jan 2017 18:38:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215969] c++ compiler regression Date: Thu, 12 Jan 2017 18:38:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:38:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215969 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |dim@FreeBSD.org --- Comment #1 from Dimitry Andric --- This problem is caused by commit https://reviews.llvm.org/rL274049, as has = been reported in the upstream PR. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Jan 12 19:24:54 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BA8CCACE0E for ; Thu, 12 Jan 2017 19:24:54 +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 BB742143B; Thu, 12 Jan 2017 19:24:53 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 4550012CACB; Thu, 12 Jan 2017 20:22:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484248943; bh=aa0i8114AsABvu10G5jY1mgsisTe4gMEvJvOTgRreSw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kr8ESIkj3eQsRtvfrlgx2d/RLldvvkW8ZeQPiH1pkYSuFm3oF/SYJhvJNCNkNacot 2DS6k7rWqo0AoBfp63Wm0uZxIzRE9GT/UyfO+0bIgQhjdJkTxLNlbt9vDDMbUiDHcl xG/Fz6L9Xd6IKu/AcKEVcx/gePHVAAGj3LFRg5UY= Date: Thu, 12 Jan 2017 20:22:23 +0100 From: Roman Divacky To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain Subject: Re: /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: <20170112192223.GA49469@vlakno.cz> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> <20170111210658.GA20265@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 19:24:54 -0000 Can you check if the TOC is correct? LLD assumes this: static uint64_t PPC64TocOffset = 0x8000; uint64_t getPPC64TocBase() { // The TOC consists of sections .got, .toc, .tocbss, .plt in that order. The // TOC starts where the first of these sections starts. We always create a // .got when we see a relocation that uses it, so for us the start is always // the .got. uint64_t TocVA = In::Got->getVA(); // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000 // thus permitting a full 64 Kbytes segment. Note that the glibc startup // code (crt1.o) assumes that you can get from the TOC base to the // start of the .toc section with only a single (signed) 16-bit relocation. return TocVA + PPC64TocOffset; } Perhaps thats not true on FreeBSD? Especially the hardcoded constant seems suspicious. When it comes to the actual PLT entry, there's this comment in the code: // FIXME: What we should do, in theory, is get the offset of the function // descriptor in the .opd section, and use that as the offset from %r2 (the // TOC-base pointer). Instead, we have the GOT-entry offset, and that will // be a pointer to the function descriptor in the .opd section. Using // this scheme is simpler, but requires an extra indirection per PLT dispatch. So I think that while it's different it might not be wrong. What might be wrong is the TOC entry (either it's content or it's position). I suspect there might be some Linux vs FreeBSD difference that prevents this from working. Roman On Thu, Jan 12, 2017 at 12:37:53AM -0800, Mark Millard wrote: > On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: > > > On 11 January 2017 at 21:06, Roman Divacky wrote: > >> Looks like a progress :) Three questions... > >> > >> Is the readelf -a reasonable now? > > > > FYI, I just committed an ELF Tool Chain fix (r311941) so readelf > > should display the relocation types properly now. > > Thanks. I updated to -r311950 to pick this up. > > >> If you compile with -g, does the > >> backtrace make a bit more sense? And finally, can you try to "nexti/stepi" in gdb from > >> _start to see where things go wrong? Possibly doing it both for ld linked a.out > >> and lld linked a.out and compare where things differ. > > I had compiled with -g. It never gets to main. . . > > # /usr/local/bin/gdb a.out > . . . > Reading symbols from a.out...done. > (gdb) start > Temporary breakpoint 1 at 0x1001045c: file main.c, line 3. > Starting program: /root/c_tests/a.out > > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () > > Note that the temporary breakpoint is never hit. > > (gdb) bt > #0 0x000000001001056c in ?? () > #1 0x00000000100100d8 in ?? () > #2 0x00000000500279b0 in ._rtld_start () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > Backtrace stopped: frame did not save the PC > > (gdb) up 2 > #2 0x00000000500279b0 in ._rtld_start () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, ps_strings) */ > (gdb) disass > Dump of assembler code for function ._rtld_start: > 0x0000000050027930 <+0>: stdu r1,-144(r1) > 0x0000000050027934 <+4>: std r3,96(r1) > 0x0000000050027938 <+8>: std r4,104(r1) > 0x000000005002793c <+12>: std r5,112(r1) > 0x0000000050027940 <+16>: std r8,136(r1) > 0x0000000050027944 <+20>: bl 0x50027950 <._rtld_start+32> > 0x0000000050027948 <+24>: .long 0x0 > 0x000000005002794c <+28>: .long 0x30e40 > 0x0000000050027950 <+32>: mflr r3 > 0x0000000050027954 <+36>: ld r4,0(r3) > 0x0000000050027958 <+40>: add r3,r4,r3 > 0x000000005002795c <+44>: ld r4,-32768(r2) > 0x0000000050027960 <+48>: subf r4,r4,r2 > 0x0000000050027964 <+52>: bl 0x50027c64 > 0x0000000050027968 <+56>: nop > 0x000000005002796c <+60>: ld r4,104(r1) > 0x0000000050027970 <+64>: addi r3,r4,-8 > 0x0000000050027974 <+68>: addi r4,r1,128 > 0x0000000050027978 <+72>: addi r5,r1,120 > 0x000000005002797c <+76>: bl 0x50028608 <_rtld> > 0x0000000050027980 <+80>: nop > 0x0000000050027984 <+84>: ld r2,8(r3) > 0x0000000050027988 <+88>: ld r11,16(r3) > 0x000000005002798c <+92>: ld r3,0(r3) > 0x0000000050027990 <+96>: mtlr r3 > 0x0000000050027994 <+100>: ld r3,96(r1) > 0x0000000050027998 <+104>: ld r4,104(r1) > 0x000000005002799c <+108>: ld r5,112(r1) > 0x00000000500279a0 <+112>: ld r6,120(r1) > 0x00000000500279a4 <+116>: ld r7,128(r1) > 0x00000000500279a8 <+120>: ld r8,136(r1) > 0x00000000500279ac <+124>: blrl > => 0x00000000500279b0 <+128>: li r0,1 > 0x00000000500279b4 <+132>: sc > 0x00000000500279b8 <+136>: nop > 0x00000000500279bc <+140>: nop > End of assembler dump. > > So setting a breakpoint at 0x00000000500279ac and > trying again: > > (gdb) run > Starting program: /root/c_tests/a.out > > Breakpoint 3, ._rtld_start () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, ps_strings) */ > (gdb) info registers > r0 0x50027980 1342339456 > r1 0xffffffffffffdaf0 18446744073709542128 > r2 0x10028138 268599608 > r3 0x1 1 > r4 0xffffffffffffdbb8 18446744073709542328 > r5 0xffffffffffffdbc8 18446744073709542344 > r6 0x5004c000 1342488576 > r7 0x50058b30 1342540592 > r8 0x0 0 > r9 0x0 0 > r10 0x0 0 > r11 0x0 0 > r12 0x20000000 536870912 > r13 0x50057010 1342533648 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x0 0 > r26 0x0 0 > r27 0x0 0 > r28 0x0 0 > r29 0x0 0 > r30 0x0 0 > r31 0x0 0 > pc 0x500279ac 0x500279ac <._rtld_start+124> > msr > cr 0x22000c00 570428416 > lr 0x10010000 0x10010000 > ctr 0x50043a80 1342454400 > xer 0x20000000 536870912 > (gdb) stepi > 0x0000000010010000 in ?? () > > and that is effectively at ._start . > > NOTE: There is no ._start name in the disassembly > listed by objdump. > > By contrast for -fuse-ld=bfd building a.out objdump shows: > > 0000000010000438 <._start> mflr r0 > 000000001000043c <._start+0x4> mfcr r12 > 0000000010000440 <._start+0x8> std r31,-8(r1) > 0000000010000444 <._start+0xc> std r0,16(r1) > 0000000010000448 <._start+0x10> stw r12,8(r1) > 000000001000044c <._start+0x14> stdu r1,-176(r1) > . . . > > > In gdb for ld.lld used: > > Reading symbols from a.out...done. > (gdb) br *0x00000000500279ac > Breakpoint 1 at 0x500279ac > (gdb) run > Starting program: /root/c_tests/a.out > > Breakpoint 1, ._rtld_start () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, ps_strings) */ > (gdb) stepi > 0x0000000010010000 in ?? () > (gdb) > 0x0000000010010004 in ?? () > (gdb) display/i $pc > 1: x/i $pc > => 0x10010004: mfcr r12 > (gdb) stepi > 0x0000000010010008 in ?? () > 1: x/i $pc > => 0x10010008: std r31,-8(r1) > (gdb) > 0x000000001001000c in ?? () > 1: x/i $pc > => 0x1001000c: std r0,16(r1) > > . . . > > (gdb) > 0x00000000100100a0 in ?? () > 1: x/i $pc > => 0x100100a0: beq 0x100100ac > (gdb) > 0x00000000100100ac in ?? () > 1: x/i $pc > => 0x100100ac: cmpldi r8,0 > (gdb) > 0x00000000100100b0 in ?? () > 1: x/i $pc > => 0x100100b0: beq 0x100100c0 > (gdb) > 0x00000000100100c0 in ?? () > 1: x/i $pc > => 0x100100c0: addis r3,r2,0 > (gdb) > 0x00000000100100c4 in ?? () > 1: x/i $pc > => 0x100100c4: ld r3,32552(r3) > (gdb) > 0x00000000100100c8 in ?? () > 1: x/i $pc > => 0x100100c8: cmpldi r3,0 > (gdb) > 0x00000000100100cc in ?? () > 1: x/i $pc > => 0x100100cc: beq 0x100100e0 > (gdb) > 0x00000000100100d0 in ?? () > 1: x/i $pc > => 0x100100d0: mr r3,r7 > (gdb) > 0x00000000100100d4 in ?? () > 1: x/i $pc > => 0x100100d4: bl 0x10010560 > > Note: Below is from plt : > > Disassembly of section .plt: > 0000000010010560 <.plt> std r2,40(r1) > 0000000010010564 <.plt+0x4> addis r11,r2,0 > 0000000010010568 <.plt+0x8> ld r12,32512(r11) > 000000001001056c <.plt+0xc> ld r11,0(r12) <<<<<===== Fails here. > 0000000010010570 <.plt+0x10> mtctr r11 > 0000000010010574 <.plt+0x14> ld r2,8(r12) > 0000000010010578 <.plt+0x18> ld r11,16(r12) > 000000001001057c <.plt+0x1c> bctr > > (By setting breakpoints in the 3 such .plt code blocks: > this is the first .plt code block executed and it fails.) > > The .plt is different from what ld.bfd generates: > no __glink_PLTresolve or its use and the code does > not appear strictly equivalent to me. > > Back to gdb based information: > > (gdb) info registers > r0 0x500279b0 1342339504 > r1 0xffffffffffffda40 18446744073709541952 > r2 0x10028138 268599608 > r3 0x50058b30 1342540592 > r4 0x0 0 > r5 0xffffffffffffdbc8 18446744073709542344 > r6 0x5004c000 1342488576 > r7 0x50058b30 1342540592 > r8 0x0 0 > r9 0x0 0 > r10 0x0 0 > r11 0x0 0 > r12 0x22000c00 570428416 > r13 0x50057010 1342533648 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x10028138 268599608 > r26 0x0 0 > r27 0x0 0 > r28 0x1 1 > r29 0xffffffffffffdbb8 18446744073709542328 > r30 0xffffffffffffdbc8 18446744073709542344 > r31 0xffffffffffffda40 18446744073709541952 > pc 0x10010560 0x10010560 > msr > cr 0x42000c00 1107299328 > lr 0x100100d8 0x100100d8 > ctr 0x50043a80 1342454400 > xer 0x20000000 536870912 > > (gdb) > 0x0000000010010560 in ?? () > 1: x/i $pc > => 0x10010560: std r2,40(r1) > (gdb) > 0x0000000010010564 in ?? () > 1: x/i $pc > => 0x10010564: addis r11,r2,0 > (gdb) > 0x0000000010010568 in ?? () > 1: x/i $pc > => 0x10010568: ld r12,32512(r11) > (gdb) > 0x000000001001056c in ?? () > 1: x/i $pc > => 0x1001056c: ld r11,0(r12) > (gdb) > > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () > 1: x/i $pc > => 0x1001056c: ld r11,0(r12) > > The source code (from lib/csu/powerpc64/crt1.c ) is: > > void > _start(int argc, char **argv, char **env, > const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), > struct ps_strings *ps_strings) > { > > handle_argv(argc, argv, env); > > if (ps_strings != (struct ps_strings *)0) > __ps_strings = ps_strings; > > if (&_DYNAMIC != NULL) > atexit(cleanup); > else > _init_tls(); > > #ifdef GCRT > atexit(_mcleanup); > monstartup(&eprol, &etext); > #endif > > handle_static_init(argc, argv, env); > exit(main(argc, argv, env)); > } > > The 3 plt code blocks are for: > > atexit > _init_tls > exit > > from what I can tell, possibly not in that order. > > Overall: The plt handling seems to be broken. > > > > You can also build rtld with additional debugging by adding -DDEBUG to > > CFLAGS. In libexec/rtld-elf/Makefile there's an example command line > > for building it locally, but I've just added CFLAGS+=-DDEBUG to the > > Makefile in my test tree and built it along with the rest of my full > > cross build. > > # svnlite diff /usr/src/libexec/rtld-elf/Makefile > Index: /usr/src/libexec/rtld-elf/Makefile > =================================================================== > --- /usr/src/libexec/rtld-elf/Makefile (revision 311950) > +++ /usr/src/libexec/rtld-elf/Makefile (working copy) > @@ -17,6 +17,7 @@ > malloc.c xmalloc.c debug.c libmap.c > MAN= rtld.1 > CSTD?= gnu99 > +CFLAGS+=-DDEBUG > CFLAGS+= -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding > CFLAGS+= -I${SRCTOP}/lib/csu/common > .if exists(${.CURDIR}/${MACHINE_ARCH}) > > The above did not seem to make much of a difference for the > code involved, likely because crt1.c is from > lib/csu/powerpc64/ instead of from libexec/rtld-elf/ . > > > === > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 13 01:59:01 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A94D8CAD7AF for ; Fri, 13 Jan 2017 01:59:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C0EF1070 for ; Fri, 13 Jan 2017 01:59:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2468 invoked from network); 13 Jan 2017 01:58:54 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Jan 2017 01:58:54 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 12 Jan 2017 20:58:54 -0500 (EST) Received: (qmail 1349 invoked from network); 13 Jan 2017 01:58:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2017 01:58:53 -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 35973EC8B12; Thu, 12 Jan 2017 17:58:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: /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 From: Mark Millard In-Reply-To: <20170112192223.GA49469@vlakno.cz> Date: Thu, 12 Jan 2017 17:58:52 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <932E3C38-B226-4BF1-B587-5A2D5EA19300@dsl-only.net> References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> <20170111210658.GA20265@vlakno.cz> <20170112192223.GA49469@vlakno.cz> To: Roman Divacky , Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 01:59:01 -0000 On 2017-Jan-12, at 11:22 AM, Roman Divacky = wrote: > Can you check if the TOC is correct? LLD assumes this: >=20 > static uint64_t PPC64TocOffset =3D 0x8000; >=20 > uint64_t getPPC64TocBase() { > // The TOC consists of sections .got, .toc, .tocbss, .plt in that = order. The > // TOC starts where the first of these sections starts. We always = create a > // .got when we see a relocation that uses it, so for us the start is = always > // the .got. > uint64_t TocVA =3D In::Got->getVA(); >=20 > // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000 > // thus permitting a full 64 Kbytes segment. Note that the glibc = startup > // code (crt1.o) assumes that you can get from the TOC base to the > // start of the .toc section with only a single (signed) 16-bit = relocation. > return TocVA + PPC64TocOffset; > } [I warn that I'm outside familiar territory here.] If I understand the 1st comment right the following does not look like a match for -fuse-dl=3Dlld (readelf -a output): Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 . . . [10] .rela.plt RELA 0000000010000420 00000420 0000000000000048 0000000000000018 A 5 0 8 . . . [15] .plt PROGBITS 0000000010010560 00010560 0000000000000060 0000000000000000 AX 0 0 16 . . . [20] .got PROGBITS 0000000010020138 00020138 0000000000000000 0000000000000000 WA 0 0 8 . . . [22] .got.plt PROGBITS 0000000010030020 00030020 0000000000000030 0000000000000000 WA 0 0 8 . . . [23] .toc PROGBITS 0000000010030050 00030050 0000000000000050 0000000000000000 WA 0 0 8 Possibly contributing reasons: A) .got is not "first" of the 4 sections (by Address or by [Nr]). (.got is listed as zero size as well) B) There is no reference to .got.plt in the comment. C) .got and .toc have .got.plt and other things between -- and .got and .got.plt have stuff between. D) There is no .tocbss at all (guess: optional so possibly okay). E) .plt is before .got by address and by [Nr] (it is als not next to .got or .got.plt or .toc). F) There is no reference to .got.plt in the comment. G) In general there are other things between the sections making them spread over a wider address range. [I guess that .rela.plt does not matter but I showed it in case I'm wrong.] Another potential issue is .plt being PROGBITS instead of NOBITS (see below). Related is AX flags above vs. WA flags below being a potential issue. By contrast for -fuse-dl-bfd I see: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 . . . [ 8] .rela.plt RELA 0000000010000370 00000370 0000000000000048 0000000000000018 A 4 22 8 . . . [21] .got PROGBITS 0000000010010c48 00000c48 0000000000000058 0000000000000008 WA 0 0 8 [22] .plt NOBITS 0000000010010ca0 00000ca0 0000000000000060 0000000000000018 WA 0 0 8 So no .toc or .tocbase sections. But .got and .plt are next to each other with .got first (by address and by [Nr]). This would fit the comments if .toc and .tocbss are optional --and apparently they are. So my guess is that -fuse-dl-bfd looks to be as expected, unlike -fuse-dl=3Dlld . > Perhaps thats not true on FreeBSD? Especially the hardcoded constant = seems suspicious. > When it comes to the actual PLT entry, there's this comment in the = code: >=20 > // FIXME: What we should do, in theory, is get the offset of the = function > // descriptor in the .opd section, and use that as the offset from = %r2 (the > // TOC-base pointer). Instead, we have the GOT-entry offset, and that = will > // be a pointer to the function descriptor in the .opd section. Using > // this scheme is simpler, but requires an extra indirection per PLT = dispatch. >=20 > So I think that while it's different it might not be wrong. What might = be wrong > is the TOC entry (either it's content or it's position). >=20 > I suspect there might be some Linux vs FreeBSD difference that = prevents this from working. >=20 > Roman =3D=3D=3D Mark Millard markmi at dsl-only.net On Thu, Jan 12, 2017 at 12:37:53AM -0800, Mark Millard wrote: > On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: >=20 >> On 11 January 2017 at 21:06, Roman Divacky = wrote: >>> Looks like a progress :) Three questions... >>>=20 >>> Is the readelf -a reasonable now? >>=20 >> FYI, I just committed an ELF Tool Chain fix (r311941) so readelf >> should display the relocation types properly now. >=20 > Thanks. I updated to -r311950 to pick this up. >=20 >>> If you compile with -g, does the >>> backtrace make a bit more sense? And finally, can you try to = "nexti/stepi" in gdb from >>> _start to see where things go wrong? Possibly doing it both for ld = linked a.out >>> and lld linked a.out and compare where things differ. >=20 > I had compiled with -g. It never gets to main. . . >=20 > # /usr/local/bin/gdb a.out > . . . > Reading symbols from a.out...done. > (gdb) start > Temporary breakpoint 1 at 0x1001045c: file main.c, line 3. > Starting program: /root/c_tests/a.out=20 >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () >=20 > Note that the temporary breakpoint is never hit. >=20 > (gdb) bt > #0 0x000000001001056c in ?? () > #1 0x00000000100100d8 in ?? () > #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > Backtrace stopped: frame did not save the PC >=20 > (gdb) up 2 > #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ > (gdb) disass > Dump of assembler code for function ._rtld_start: > 0x0000000050027930 <+0>: stdu r1,-144(r1) > 0x0000000050027934 <+4>: std r3,96(r1) > 0x0000000050027938 <+8>: std r4,104(r1) > 0x000000005002793c <+12>: std r5,112(r1) > 0x0000000050027940 <+16>: std r8,136(r1) > 0x0000000050027944 <+20>: bl 0x50027950 <._rtld_start+32> > 0x0000000050027948 <+24>: .long 0x0 > 0x000000005002794c <+28>: .long 0x30e40 > 0x0000000050027950 <+32>: mflr r3 > 0x0000000050027954 <+36>: ld r4,0(r3) > 0x0000000050027958 <+40>: add r3,r4,r3 > 0x000000005002795c <+44>: ld r4,-32768(r2) > 0x0000000050027960 <+48>: subf r4,r4,r2 > 0x0000000050027964 <+52>: bl 0x50027c64 > 0x0000000050027968 <+56>: nop > 0x000000005002796c <+60>: ld r4,104(r1) > 0x0000000050027970 <+64>: addi r3,r4,-8 > 0x0000000050027974 <+68>: addi r4,r1,128 > 0x0000000050027978 <+72>: addi r5,r1,120 > 0x000000005002797c <+76>: bl 0x50028608 <_rtld> > 0x0000000050027980 <+80>: nop > 0x0000000050027984 <+84>: ld r2,8(r3) > 0x0000000050027988 <+88>: ld r11,16(r3) > 0x000000005002798c <+92>: ld r3,0(r3) > 0x0000000050027990 <+96>: mtlr r3 > 0x0000000050027994 <+100>: ld r3,96(r1) > 0x0000000050027998 <+104>: ld r4,104(r1) > 0x000000005002799c <+108>: ld r5,112(r1) > 0x00000000500279a0 <+112>: ld r6,120(r1) > 0x00000000500279a4 <+116>: ld r7,128(r1) > 0x00000000500279a8 <+120>: ld r8,136(r1) > 0x00000000500279ac <+124>: blrl > =3D> 0x00000000500279b0 <+128>: li r0,1 > 0x00000000500279b4 <+132>: sc =20 > 0x00000000500279b8 <+136>: nop > 0x00000000500279bc <+140>: nop > End of assembler dump. >=20 > So setting a breakpoint at 0x00000000500279ac and > trying again: >=20 > (gdb) run > Starting program: /root/c_tests/a.out=20 >=20 > Breakpoint 3, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ > (gdb) info registers > r0 0x50027980 1342339456 > r1 0xffffffffffffdaf0 18446744073709542128 > r2 0x10028138 268599608 > r3 0x1 1 > r4 0xffffffffffffdbb8 18446744073709542328 > r5 0xffffffffffffdbc8 18446744073709542344 > r6 0x5004c000 1342488576 > r7 0x50058b30 1342540592 > r8 0x0 0 > r9 0x0 0 > r10 0x0 0 > r11 0x0 0 > r12 0x20000000 536870912 > r13 0x50057010 1342533648 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x0 0 > r26 0x0 0 > r27 0x0 0 > r28 0x0 0 > r29 0x0 0 > r30 0x0 0 > r31 0x0 0 > pc 0x500279ac 0x500279ac <._rtld_start+124> > msr > cr 0x22000c00 570428416 > lr 0x10010000 0x10010000 > ctr 0x50043a80 1342454400 > xer 0x20000000 536870912 > (gdb) stepi > 0x0000000010010000 in ?? () >=20 > and that is effectively at ._start . >=20 > NOTE: There is no ._start name in the disassembly > listed by objdump. >=20 > By contrast for -fuse-ld=3Dbfd building a.out objdump shows: >=20 > 0000000010000438 <._start> mflr r0 > 000000001000043c <._start+0x4> mfcr r12 > 0000000010000440 <._start+0x8> std r31,-8(r1) > 0000000010000444 <._start+0xc> std r0,16(r1) > 0000000010000448 <._start+0x10> stw r12,8(r1) > 000000001000044c <._start+0x14> stdu r1,-176(r1) > . . . >=20 >=20 > In gdb for ld.lld used: >=20 > Reading symbols from a.out...done. > (gdb) br *0x00000000500279ac > Breakpoint 1 at 0x500279ac > (gdb) run > Starting program: /root/c_tests/a.out=20 >=20 > Breakpoint 1, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ > (gdb) stepi > 0x0000000010010000 in ?? () > (gdb)=20 > 0x0000000010010004 in ?? () > (gdb) display/i $pc > 1: x/i $pc > =3D> 0x10010004: mfcr r12 > (gdb) stepi > 0x0000000010010008 in ?? () > 1: x/i $pc > =3D> 0x10010008: std r31,-8(r1) > (gdb)=20 > 0x000000001001000c in ?? () > 1: x/i $pc > =3D> 0x1001000c: std r0,16(r1) >=20 > . . . >=20 > (gdb)=20 > 0x00000000100100a0 in ?? () > 1: x/i $pc > =3D> 0x100100a0: beq 0x100100ac > (gdb)=20 > 0x00000000100100ac in ?? () > 1: x/i $pc > =3D> 0x100100ac: cmpldi r8,0 > (gdb)=20 > 0x00000000100100b0 in ?? () > 1: x/i $pc > =3D> 0x100100b0: beq 0x100100c0 > (gdb)=20 > 0x00000000100100c0 in ?? () > 1: x/i $pc > =3D> 0x100100c0: addis r3,r2,0 > (gdb)=20 > 0x00000000100100c4 in ?? () > 1: x/i $pc > =3D> 0x100100c4: ld r3,32552(r3) > (gdb)=20 > 0x00000000100100c8 in ?? () > 1: x/i $pc > =3D> 0x100100c8: cmpldi r3,0 > (gdb)=20 > 0x00000000100100cc in ?? () > 1: x/i $pc > =3D> 0x100100cc: beq 0x100100e0 > (gdb)=20 > 0x00000000100100d0 in ?? () > 1: x/i $pc > =3D> 0x100100d0: mr r3,r7 > (gdb)=20 > 0x00000000100100d4 in ?? () > 1: x/i $pc > =3D> 0x100100d4: bl 0x10010560 >=20 > Note: Below is from plt : >=20 > Disassembly of section .plt: > 0000000010010560 <.plt> std r2,40(r1) > 0000000010010564 <.plt+0x4> addis r11,r2,0 > 0000000010010568 <.plt+0x8> ld r12,32512(r11) > 000000001001056c <.plt+0xc> ld r11,0(r12) <<<<<=3D=3D=3D=3D=3D = Fails here. > 0000000010010570 <.plt+0x10> mtctr r11 > 0000000010010574 <.plt+0x14> ld r2,8(r12) > 0000000010010578 <.plt+0x18> ld r11,16(r12) > 000000001001057c <.plt+0x1c> bctr >=20 > (By setting breakpoints in the 3 such .plt code blocks: > this is the first .plt code block executed and it fails.) >=20 > The .plt is different from what ld.bfd generates: > no __glink_PLTresolve or its use and the code does > not appear strictly equivalent to me. >=20 > Back to gdb based information: >=20 > (gdb) info registers > r0 0x500279b0 1342339504 > r1 0xffffffffffffda40 18446744073709541952 > r2 0x10028138 268599608 > r3 0x50058b30 1342540592 > r4 0x0 0 > r5 0xffffffffffffdbc8 18446744073709542344 > r6 0x5004c000 1342488576 > r7 0x50058b30 1342540592 > r8 0x0 0 > r9 0x0 0 > r10 0x0 0 > r11 0x0 0 > r12 0x22000c00 570428416 > r13 0x50057010 1342533648 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x10028138 268599608 > r26 0x0 0 > r27 0x0 0 > r28 0x1 1 > r29 0xffffffffffffdbb8 18446744073709542328 > r30 0xffffffffffffdbc8 18446744073709542344 > r31 0xffffffffffffda40 18446744073709541952 > pc 0x10010560 0x10010560 > msr > cr 0x42000c00 1107299328 > lr 0x100100d8 0x100100d8 > ctr 0x50043a80 1342454400 > xer 0x20000000 536870912 >=20 > (gdb)=20 > 0x0000000010010560 in ?? () > 1: x/i $pc > =3D> 0x10010560: std r2,40(r1) > (gdb)=20 > 0x0000000010010564 in ?? () > 1: x/i $pc > =3D> 0x10010564: addis r11,r2,0 > (gdb)=20 > 0x0000000010010568 in ?? () > 1: x/i $pc > =3D> 0x10010568: ld r12,32512(r11) > (gdb)=20 > 0x000000001001056c in ?? () > 1: x/i $pc > =3D> 0x1001056c: ld r11,0(r12) > (gdb)=20 >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () > 1: x/i $pc > =3D> 0x1001056c: ld r11,0(r12) >=20 > The source code (from lib/csu/powerpc64/crt1.c ) is: >=20 > void > _start(int argc, char **argv, char **env, > const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), > struct ps_strings *ps_strings) > { >=20 > handle_argv(argc, argv, env); >=20 > if (ps_strings !=3D (struct ps_strings *)0) > __ps_strings =3D ps_strings; >=20 > if (&_DYNAMIC !=3D NULL) > atexit(cleanup); > else > _init_tls(); >=20 > #ifdef GCRT > atexit(_mcleanup); > monstartup(&eprol, &etext); > #endif >=20 > handle_static_init(argc, argv, env); > exit(main(argc, argv, env)); > } >=20 > The 3 plt code blocks are for: >=20 > atexit > _init_tls > exit >=20 > from what I can tell, possibly not in that order. >=20 > Overall: The plt handling seems to be broken. >=20 >=20 >> You can also build rtld with additional debugging by adding -DDEBUG = to >> CFLAGS. In libexec/rtld-elf/Makefile there's an example command line >> for building it locally, but I've just added CFLAGS+=3D-DDEBUG to the >> Makefile in my test tree and built it along with the rest of my full >> cross build. >=20 > # svnlite diff /usr/src/libexec/rtld-elf/Makefile > Index: /usr/src/libexec/rtld-elf/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/libexec/rtld-elf/Makefile (revision 311950) > +++ /usr/src/libexec/rtld-elf/Makefile (working copy) > @@ -17,6 +17,7 @@ > malloc.c xmalloc.c debug.c libmap.c > MAN=3D rtld.1 > CSTD?=3D gnu99 > +CFLAGS+=3D-DDEBUG > CFLAGS+=3D -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding > CFLAGS+=3D -I${SRCTOP}/lib/csu/common > .if exists(${.CURDIR}/${MACHINE_ARCH}) >=20 > The above did not seem to make much of a difference for the > code involved, likely because crt1.c is from > lib/csu/powerpc64/ instead of from libexec/rtld-elf/ . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jan 13 02:55:53 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D198DCAD200 for ; Fri, 13 Jan 2017 02:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99E1F1458 for ; Fri, 13 Jan 2017 02:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0D2tr4j043685 for ; Fri, 13 Jan 2017 02:55:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216012] /usr/lib/libgcc_s.so underlinks libc after r308308 Date: Fri, 13 Jan 2017 02:55:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 02:55:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216012 Bug ID: 216012 Summary: /usr/lib/libgcc_s.so underlinks libc after r308308 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: regression Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org Below example is a snippet from configure check in www/firefox. Rebuilding world WITHOUT_LLVM_LIBUNWIND=3D1 makes the issue disappear. $ pkg install -qy binutils fontconfig $ mkdir gold $ ln -s /usr/local/bin/ld.gold gold/ld $ echo 'int main() {}' >a.c $ cc -Bgold -L/usr/local/lib -lfontconfig a.c /usr/lib/libgcc_s.so: error: undefined reference to 'free' /usr/lib/libgcc_s.so: error: undefined reference to 'malloc' /usr/lib/libgcc_s.so: error: undefined reference to '__stderrp' /usr/lib/libgcc_s.so: error: undefined reference to 'memcpy' /usr/lib/libgcc_s.so: error: undefined reference to 'getenv' /usr/lib/libgcc_s.so: error: undefined reference to 'abort' /usr/lib/libgcc_s.so: error: undefined reference to 'fflush' /usr/lib/libgcc_s.so: error: undefined reference to 'memset' /usr/lib/libgcc_s.so: error: undefined reference to '__assert' /usr/lib/libgcc_s.so: error: undefined reference to 'snprintf' /usr/lib/libgcc_s.so: error: undefined reference to 'fprintf' /usr/lib/libgcc_s.so: error: undefined reference to 'fwrite' cc: error: linker command failed with exit code 1 (use -v to see invocation) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 13 03:06:33 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C87D0CAD72E for ; Fri, 13 Jan 2017 03:06:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4183A110C for ; Fri, 13 Jan 2017 03:06: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 v0D36WPa051959 for ; Fri, 13 Jan 2017 03:06:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216012] /usr/lib/libgcc_s.so underlinks libc breaking linking with ld.gold Date: Fri, 13 Jan 2017 03:06:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc blocked Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:06:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216012 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|/usr/lib/libgcc_s.so |/usr/lib/libgcc_s.so |underlinks libc after |underlinks libc breaking |r308308 |linking with ld.gold Blocks| |213480 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213480 [Bug 213480] [exp-run] switch to compiler-rt & LLVM libunwind for libgcc_eh= .a and libgcc_s.so --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 13 03:13:14 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 368ABCADAA4 for ; Fri, 13 Jan 2017 03:13:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 260D217F7 for ; Fri, 13 Jan 2017 03:13:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0D3DEtT005389 for ; Fri, 13 Jan 2017 03:13:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216012] /usr/lib/libgcc_s.so underlinks libc breaking linking with ld.gold Date: Fri, 13 Jan 2017 03:13:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emaste@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:13:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216012 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org Assignee|freebsd-toolchain@FreeBSD.o |emaste@freebsd.org |rg | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Jan 13 22:07:04 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBC97CAE51C for ; Fri, 13 Jan 2017 22:07:04 +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 8E8E310C3 for ; Fri, 13 Jan 2017 22:07:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29822 invoked from network); 13 Jan 2017 22:07:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Jan 2017 22:07:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Fri, 13 Jan 2017 17:07:02 -0500 (EST) Received: (qmail 16636 invoked from network); 13 Jan 2017 22:07:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2017 22:07:02 -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 76E0AEC91F6; Fri, 13 Jan 2017 14:07:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: /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 From: Mark Millard In-Reply-To: <932E3C38-B226-4BF1-B587-5A2D5EA19300@dsl-only.net> Date: Fri, 13 Jan 2017 14:07:00 -0800 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <7139F615-8F18-4EDC-9051-5FFEC0C4057F@dsl-only.net> <20170111194844.GA16135@vlakno.cz> <8242A7B9-7ED3-4861-8209-F3728113D188@dsl-only.net> <20170111210658.GA20265@vlakno.cz> <20170112192223.GA49469@vlakno.cz> <932E3C38-B226-4BF1-B587-5A2D5EA19300@dsl-only.net> To: Roman Divacky , Ed Maste X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:07:04 -0000 Just an FYI: elfdump -a (from -r311950) does not dump .plt or .got.plt or .toc : # elfdump -a a.out | egrep "(got|toc|plt|:$)" | more elf header: program header: section header: sh_name: .rela.plt sh_name: .plt sh_name: .got sh_name: .got.plt sh_name: .toc interp: symbol table (.dynsym): relocation with addend (.rela.plt): dynamic: global offset table: symbol table (.symtab): (The "global offset table" was empty but its title was listed.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-12, at 5:58 PM, Mark Millard wrote: On 2017-Jan-12, at 11:22 AM, Roman Divacky = wrote: > Can you check if the TOC is correct? LLD assumes this: >=20 > static uint64_t PPC64TocOffset =3D 0x8000; >=20 > uint64_t getPPC64TocBase() { > // The TOC consists of sections .got, .toc, .tocbss, .plt in that = order. The > // TOC starts where the first of these sections starts. We always = create a > // .got when we see a relocation that uses it, so for us the start is = always > // the .got. > uint64_t TocVA =3D In::Got->getVA(); >=20 > // Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000 > // thus permitting a full 64 Kbytes segment. Note that the glibc = startup > // code (crt1.o) assumes that you can get from the TOC base to the > // start of the .toc section with only a single (signed) 16-bit = relocation. > return TocVA + PPC64TocOffset; > } [I warn that I'm outside familiar territory here.] If I understand the 1st comment right the following does not look like a match for -fuse-dl=3Dlld (readelf -a output): Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 . . . [10] .rela.plt RELA 0000000010000420 00000420 0000000000000048 0000000000000018 A 5 0 8 . . . [15] .plt PROGBITS 0000000010010560 00010560 0000000000000060 0000000000000000 AX 0 0 16 . . . [20] .got PROGBITS 0000000010020138 00020138 0000000000000000 0000000000000000 WA 0 0 8 . . . [22] .got.plt PROGBITS 0000000010030020 00030020 0000000000000030 0000000000000000 WA 0 0 8 . . . [23] .toc PROGBITS 0000000010030050 00030050 0000000000000050 0000000000000000 WA 0 0 8 Possibly contributing reasons: A) .got is not "first" of the 4 sections (by Address or by [Nr]). (.got is listed as zero size as well) B) There is no reference to .got.plt in the comment. C) .got and .toc have .got.plt and other things between -- and .got and .got.plt have stuff between. D) There is no .tocbss at all (guess: optional so possibly okay). E) .plt is before .got by address and by [Nr] (it is als not next to .got or .got.plt or .toc). F) There is no reference to .got.plt in the comment. G) In general there are other things between the sections making them spread over a wider address range. [I guess that .rela.plt does not matter but I showed it in case I'm wrong.] Another potential issue is .plt being PROGBITS instead of NOBITS (see below). Related is AX flags above vs. WA flags below being a potential issue. By contrast for -fuse-dl-bfd I see: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 . . . [ 8] .rela.plt RELA 0000000010000370 00000370 0000000000000048 0000000000000018 A 4 22 8 . . . [21] .got PROGBITS 0000000010010c48 00000c48 0000000000000058 0000000000000008 WA 0 0 8 [22] .plt NOBITS 0000000010010ca0 00000ca0 0000000000000060 0000000000000018 WA 0 0 8 So no .toc or .tocbase sections. But .got and .plt are next to each other with .got first (by address and by [Nr]). This would fit the comments if .toc and .tocbss are optional --and apparently they are. So my guess is that -fuse-dl-bfd looks to be as expected, unlike -fuse-dl=3Dlld . > Perhaps thats not true on FreeBSD? Especially the hardcoded constant = seems suspicious. > When it comes to the actual PLT entry, there's this comment in the = code: >=20 > // FIXME: What we should do, in theory, is get the offset of the = function > // descriptor in the .opd section, and use that as the offset from %r2 = (the > // TOC-base pointer). Instead, we have the GOT-entry offset, and that = will > // be a pointer to the function descriptor in the .opd section. Using > // this scheme is simpler, but requires an extra indirection per PLT = dispatch. >=20 > So I think that while it's different it might not be wrong. What might = be wrong > is the TOC entry (either it's content or it's position). >=20 > I suspect there might be some Linux vs FreeBSD difference that = prevents this from working. >=20 > Roman =3D=3D=3D Mark Millard markmi at dsl-only.net On Thu, Jan 12, 2017 at 12:37:53AM -0800, Mark Millard wrote: > On 2017-Jan-11, at 1:23 PM, Ed Maste wrote: >=20 >> On 11 January 2017 at 21:06, Roman Divacky = wrote: >>> Looks like a progress :) Three questions... >>>=20 >>> Is the readelf -a reasonable now? >>=20 >> FYI, I just committed an ELF Tool Chain fix (r311941) so readelf >> should display the relocation types properly now. >=20 > Thanks. I updated to -r311950 to pick this up. >=20 >>> If you compile with -g, does the >>> backtrace make a bit more sense? And finally, can you try to = "nexti/stepi" in gdb from >>> _start to see where things go wrong? Possibly doing it both for ld = linked a.out >>> and lld linked a.out and compare where things differ. >=20 > I had compiled with -g. It never gets to main. . . >=20 > # /usr/local/bin/gdb a.out > . . . > Reading symbols from a.out...done. > (gdb) start > Temporary breakpoint 1 at 0x1001045c: file main.c, line 3. > Starting program: /root/c_tests/a.out=20 >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () >=20 > Note that the temporary breakpoint is never hit. >=20 > (gdb) bt > #0 0x000000001001056c in ?? () > #1 0x00000000100100d8 in ?? () > #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > Backtrace stopped: frame did not save the PC >=20 > (gdb) up 2 > #2 0x00000000500279b0 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ > (gdb) disass > Dump of assembler code for function ._rtld_start: > 0x0000000050027930 <+0>: stdu r1,-144(r1) > 0x0000000050027934 <+4>: std r3,96(r1) > 0x0000000050027938 <+8>: std r4,104(r1) > 0x000000005002793c <+12>: std r5,112(r1) > 0x0000000050027940 <+16>: std r8,136(r1) > 0x0000000050027944 <+20>: bl 0x50027950 <._rtld_start+32> > 0x0000000050027948 <+24>: .long 0x0 > 0x000000005002794c <+28>: .long 0x30e40 > 0x0000000050027950 <+32>: mflr r3 > 0x0000000050027954 <+36>: ld r4,0(r3) > 0x0000000050027958 <+40>: add r3,r4,r3 > 0x000000005002795c <+44>: ld r4,-32768(r2) > 0x0000000050027960 <+48>: subf r4,r4,r2 > 0x0000000050027964 <+52>: bl 0x50027c64 > 0x0000000050027968 <+56>: nop > 0x000000005002796c <+60>: ld r4,104(r1) > 0x0000000050027970 <+64>: addi r3,r4,-8 > 0x0000000050027974 <+68>: addi r4,r1,128 > 0x0000000050027978 <+72>: addi r5,r1,120 > 0x000000005002797c <+76>: bl 0x50028608 <_rtld> > 0x0000000050027980 <+80>: nop > 0x0000000050027984 <+84>: ld r2,8(r3) > 0x0000000050027988 <+88>: ld r11,16(r3) > 0x000000005002798c <+92>: ld r3,0(r3) > 0x0000000050027990 <+96>: mtlr r3 > 0x0000000050027994 <+100>: ld r3,96(r1) > 0x0000000050027998 <+104>: ld r4,104(r1) > 0x000000005002799c <+108>: ld r5,112(r1) > 0x00000000500279a0 <+112>: ld r6,120(r1) > 0x00000000500279a4 <+116>: ld r7,128(r1) > 0x00000000500279a8 <+120>: ld r8,136(r1) > 0x00000000500279ac <+124>: blrl > =3D> 0x00000000500279b0 <+128>: li r0,1 > 0x00000000500279b4 <+132>: sc =20 > 0x00000000500279b8 <+136>: nop > 0x00000000500279bc <+140>: nop > End of assembler dump. >=20 > So setting a breakpoint at 0x00000000500279ac and > trying again: >=20 > (gdb) run > Starting program: /root/c_tests/a.out=20 >=20 > Breakpoint 3, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ > (gdb) info registers > r0 0x50027980 1342339456 > r1 0xffffffffffffdaf0 18446744073709542128 > r2 0x10028138 268599608 > r3 0x1 1 > r4 0xffffffffffffdbb8 18446744073709542328 > r5 0xffffffffffffdbc8 18446744073709542344 > r6 0x5004c000 1342488576 > r7 0x50058b30 1342540592 > r8 0x0 0 > r9 0x0 0 > r10 0x0 0 > r11 0x0 0 > r12 0x20000000 536870912 > r13 0x50057010 1342533648 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x0 0 > r26 0x0 0 > r27 0x0 0 > r28 0x0 0 > r29 0x0 0 > r30 0x0 0 > r31 0x0 0 > pc 0x500279ac 0x500279ac <._rtld_start+124> > msr > cr 0x22000c00 570428416 > lr 0x10010000 0x10010000 > ctr 0x50043a80 1342454400 > xer 0x20000000 536870912 > (gdb) stepi > 0x0000000010010000 in ?? () >=20 > and that is effectively at ._start . >=20 > NOTE: There is no ._start name in the disassembly > listed by objdump. >=20 > By contrast for -fuse-ld=3Dbfd building a.out objdump shows: >=20 > 0000000010000438 <._start> mflr r0 > 000000001000043c <._start+0x4> mfcr r12 > 0000000010000440 <._start+0x8> std r31,-8(r1) > 0000000010000444 <._start+0xc> std r0,16(r1) > 0000000010000448 <._start+0x10> stw r12,8(r1) > 000000001000044c <._start+0x14> stdu r1,-176(r1) > . . . >=20 >=20 > In gdb for ld.lld used: >=20 > Reading symbols from a.out...done. > (gdb) br *0x00000000500279ac > Breakpoint 1 at 0x500279ac > (gdb) run > Starting program: /root/c_tests/a.out=20 >=20 > Breakpoint 1, ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ > (gdb) stepi > 0x0000000010010000 in ?? () > (gdb)=20 > 0x0000000010010004 in ?? () > (gdb) display/i $pc > 1: x/i $pc > =3D> 0x10010004: mfcr r12 > (gdb) stepi > 0x0000000010010008 in ?? () > 1: x/i $pc > =3D> 0x10010008: std r31,-8(r1) > (gdb)=20 > 0x000000001001000c in ?? () > 1: x/i $pc > =3D> 0x1001000c: std r0,16(r1) >=20 > . . . >=20 > (gdb)=20 > 0x00000000100100a0 in ?? () > 1: x/i $pc > =3D> 0x100100a0: beq 0x100100ac > (gdb)=20 > 0x00000000100100ac in ?? () > 1: x/i $pc > =3D> 0x100100ac: cmpldi r8,0 > (gdb)=20 > 0x00000000100100b0 in ?? () > 1: x/i $pc > =3D> 0x100100b0: beq 0x100100c0 > (gdb)=20 > 0x00000000100100c0 in ?? () > 1: x/i $pc > =3D> 0x100100c0: addis r3,r2,0 > (gdb)=20 > 0x00000000100100c4 in ?? () > 1: x/i $pc > =3D> 0x100100c4: ld r3,32552(r3) > (gdb)=20 > 0x00000000100100c8 in ?? () > 1: x/i $pc > =3D> 0x100100c8: cmpldi r3,0 > (gdb)=20 > 0x00000000100100cc in ?? () > 1: x/i $pc > =3D> 0x100100cc: beq 0x100100e0 > (gdb)=20 > 0x00000000100100d0 in ?? () > 1: x/i $pc > =3D> 0x100100d0: mr r3,r7 > (gdb)=20 > 0x00000000100100d4 in ?? () > 1: x/i $pc > =3D> 0x100100d4: bl 0x10010560 >=20 > Note: Below is from plt : >=20 > Disassembly of section .plt: > 0000000010010560 <.plt> std r2,40(r1) > 0000000010010564 <.plt+0x4> addis r11,r2,0 > 0000000010010568 <.plt+0x8> ld r12,32512(r11) > 000000001001056c <.plt+0xc> ld r11,0(r12) <<<<<=3D=3D=3D=3D=3D = Fails here. > 0000000010010570 <.plt+0x10> mtctr r11 > 0000000010010574 <.plt+0x14> ld r2,8(r12) > 0000000010010578 <.plt+0x18> ld r11,16(r12) > 000000001001057c <.plt+0x1c> bctr >=20 > (By setting breakpoints in the 3 such .plt code blocks: > this is the first .plt code block executed and it fails.) >=20 > The .plt is different from what ld.bfd generates: > no __glink_PLTresolve or its use and the code does > not appear strictly equivalent to me. >=20 > Back to gdb based information: >=20 > (gdb) info registers > r0 0x500279b0 1342339504 > r1 0xffffffffffffda40 18446744073709541952 > r2 0x10028138 268599608 > r3 0x50058b30 1342540592 > r4 0x0 0 > r5 0xffffffffffffdbc8 18446744073709542344 > r6 0x5004c000 1342488576 > r7 0x50058b30 1342540592 > r8 0x0 0 > r9 0x0 0 > r10 0x0 0 > r11 0x0 0 > r12 0x22000c00 570428416 > r13 0x50057010 1342533648 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x10028138 268599608 > r26 0x0 0 > r27 0x0 0 > r28 0x1 1 > r29 0xffffffffffffdbb8 18446744073709542328 > r30 0xffffffffffffdbc8 18446744073709542344 > r31 0xffffffffffffda40 18446744073709541952 > pc 0x10010560 0x10010560 > msr > cr 0x42000c00 1107299328 > lr 0x100100d8 0x100100d8 > ctr 0x50043a80 1342454400 > xer 0x20000000 536870912 >=20 > (gdb)=20 > 0x0000000010010560 in ?? () > 1: x/i $pc > =3D> 0x10010560: std r2,40(r1) > (gdb)=20 > 0x0000000010010564 in ?? () > 1: x/i $pc > =3D> 0x10010564: addis r11,r2,0 > (gdb)=20 > 0x0000000010010568 in ?? () > 1: x/i $pc > =3D> 0x10010568: ld r12,32512(r11) > (gdb)=20 > 0x000000001001056c in ?? () > 1: x/i $pc > =3D> 0x1001056c: ld r11,0(r12) > (gdb)=20 >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x000000001001056c in ?? () > 1: x/i $pc > =3D> 0x1001056c: ld r11,0(r12) >=20 > The source code (from lib/csu/powerpc64/crt1.c ) is: >=20 > void > _start(int argc, char **argv, char **env, > const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void), > struct ps_strings *ps_strings) > { >=20 > handle_argv(argc, argv, env); >=20 > if (ps_strings !=3D (struct ps_strings *)0) > __ps_strings =3D ps_strings; >=20 > if (&_DYNAMIC !=3D NULL) > atexit(cleanup); > else > _init_tls(); >=20 > #ifdef GCRT > atexit(_mcleanup); > monstartup(&eprol, &etext); > #endif >=20 > handle_static_init(argc, argv, env); > exit(main(argc, argv, env)); > } >=20 > The 3 plt code blocks are for: >=20 > atexit > _init_tls > exit >=20 > from what I can tell, possibly not in that order. >=20 > Overall: The plt handling seems to be broken. >=20 >=20 >> You can also build rtld with additional debugging by adding -DDEBUG = to >> CFLAGS. In libexec/rtld-elf/Makefile there's an example command line >> for building it locally, but I've just added CFLAGS+=3D-DDEBUG to the >> Makefile in my test tree and built it along with the rest of my full >> cross build. >=20 > # svnlite diff /usr/src/libexec/rtld-elf/Makefile > Index: /usr/src/libexec/rtld-elf/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/libexec/rtld-elf/Makefile (revision 311950) > +++ /usr/src/libexec/rtld-elf/Makefile (working copy) > @@ -17,6 +17,7 @@ > malloc.c xmalloc.c debug.c libmap.c > MAN=3D rtld.1 > CSTD?=3D gnu99 > +CFLAGS+=3D-DDEBUG > CFLAGS+=3D -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding > CFLAGS+=3D -I${SRCTOP}/lib/csu/common > .if exists(${.CURDIR}/${MACHINE_ARCH}) >=20 > The above did not seem to make much of a difference for the > code involved, likely because crt1.c is from > lib/csu/powerpc64/ instead of from libexec/rtld-elf/ . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sat Jan 14 14:31:45 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95401CAE8B5 for ; Sat, 14 Jan 2017 14:31:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EA441934 for ; Sat, 14 Jan 2017 14:31:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0EEVjEX085714 for ; Sat, 14 Jan 2017 14:31:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215969] c++ compiler regression Date: Sat, 14 Jan 2017 14:31:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kami@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 14:31:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215969 --- Comment #2 from Dominic Fandrey --- There has been an upstream commit: http://llvm.org/viewvc/llvm-project?view=3Drevision&revision=3D291955 --=20 You are receiving this mail because: You are the assignee for the bug.=