Date: Fri, 06 Jan 2017 07:29:07 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@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 Message-ID: <bug-215819-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215819 Bug ID: 215819 Summary: 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 Product: Base System Version: CURRENT Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: markmi@dsl-only.net /boot/kernel/kernel for powerpc64 ends up with 0(r2) use and the like where it should involve more like -32760 . Note that a devel/*binutils must be used because the bootstrapped binutils has other problems. (I intend a submittal for that as well at some point.) [Note: In order to get this far I've got other workarounds for other issues that allowed exploring for "the next problem".] [I expect this submittal also applies to stable/11's clang 3.9.1 but I've not explored that environment yet.] It turns out that this 0(r2) type of code traces back to the locore.o that is generated: Using objdump on locore.o I see variations based on clang vs. xtoolchain, including the below relative to .toc handling: (- -> clang , + -> xtoolchain) RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE=20 . . . -0000000000000046 R_PPC64_ADDR16_DS .toc +0000000000000046 R_PPC64_TOC16_DS .toc . . . -0000000000000182 R_PPC64_ADDR16_DS .toc +0000000000000182 R_PPC64_TOC16_DS .toc . . . -0000000000000916 R_PPC64_ADDR16_DS .toc . . . +0000000000000916 R_PPC64_TOC16_DS .toc . . . In the boot code (/boot/kernel/kernel) these match up with. . . Disassembly of section .text: 0000000000100160 <.__start> mfmsr r20 # clang vs. Disassembly of section .text: 0000000000100120 <.__start> mfmsr r20 # xtoolchain . . . 00000000001001a4 <.__start+0x44> ld r1,0(r2) # 100160+46 clang vs. 0000000000100164 <.__start+0x44> ld r1,-32760(r2) # 100120+46 xtoolch= ain . . . 00000000001002e0 <rstcodeend+0x8> ld r1,0(r2) # 100160+182 clang vs. 00000000001002a0 <rstcodeend+0x8> ld r1,-32760(r2) # 100120+182 xtoolc= hain . . . 0000000000100a74 <dbtrap+0x10> ld r1,0(r1) # 100160+916 clang vs. 0000000000100a34 <dbtrap+0x10> ld r1,-32760(r1) # 100120+916 xtoolc= hain clang's code does not boot; xtoolchain's code does. I do not know if clang's use of R_PPC64_ADDR16_DS here is somehow specific to FreeBSD's variant or not. It may or may not need fixes from llvm (based on my ignorance). The actual failure example is (from a PowerMac G5 so-called "Quad Core"): Booting. . . Kernel entry at 0x100160 Invalid memory access at %SSR0: 00000000.001001b0 %SRR1:90000000.000030= 30 >From objdump: 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=3D=3D=3D != !!!! booting xtoolchain based kernel has: r1,-32760(r2) above <<<=3D=3D=3D !!!= !! 00000000001001a8 <.__start+0x48> addi r1,r1,16288 00000000001001ac <.__start+0x4c> add r1,r1,r31 00000000001001b0 <.__start+0x50> std r3,48(r1) (Code from cross builds can be inspected even if one does not have powerpc64 hardware.) Showing the SRC_ENV_CONF file for cross-builds (amd64 -> powerpc64) based on the (failing) clang and on using devel/powerpc64-binutils : (It references a KERNCONF of mine that includes a standard one.) # more ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-h= ost=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 Note: Most of my powerpc64 experiments so far have been based on 2.25 vintage devel/*binutils instead of 2.27 vintage. I need to do some experiments updating but I expect that 2.27 would work fine with the xtoolchain use of R_PPC64_TOC16_DS . As for xtoolchain's SRC_ENV_CONF file: (It references a KERNCONF of mine that includes a standard one.) # more ~/src.configs/src.conf.powerpc64-xtoolchain.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 # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_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 # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried # but the LIB32 does not work [crtbeginS code problem(s)] WITHOUT_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Avoid db_trace.o getting: # calling '__builtin_frame_address' with a nonzero argument is unsafe # as an error? Other such points as well. 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_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++ XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp .export XCC .export XCXX .export XCPP 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 # # # From based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP As for where I've got tailoring and/or workarounds: # 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/trap_subr32.S M /usr/src/sys/powerpc/ofw/ofw_machdep.c --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-215819-8>