[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
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Jan 6 07:29:07 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819
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 at FreeBSD.org
Reporter: markmi at 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
. . .
-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 xtoolchain
. . .
00000000001002e0 <rstcodeend+0x8> ld r1,0(r2) # 100160+182 clang
vs.
00000000001002a0 <rstcodeend+0x8> ld r1,-32760(r2) # 100120+182 xtoolchain
. . .
0000000000100a74 <dbtrap+0x10> ld r1,0(r1) # 100160+916 clang
vs.
0000000000100a34 <dbtrap+0x10> ld r1,-32760(r1) # 100120+916 xtoolchain
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.00003030
>From objdump:
00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=== !!!!!
booting xtoolchain based kernel has: r1,-32760(r2) above <<<=== !!!!!
00000000001001a8 <.__start+0x48> addi r1,r1,16288
00000000001001ac <.__start+0x4c> add r1,r1,r31
00000000001001b0 <.__start+0x50> std r3,48(r1)
(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-host
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
#
# 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=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/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
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#
WITH_BOOT=
# 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=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
# Avoid db_trace.o getting:
# calling '__builtin_frame_address' with a nonzero argument is unsafe
# as an error? Other such points as well.
WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
#
# 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=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/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} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/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
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list