[Bug 215821] head -r311147's ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Jan 6 08:36:22 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215821
Bug ID: 215821
Summary: head -r311147's ld for TARGET_ARCH=powerpc64 produces
kernel.full as a "shared object" for -pie instead of
as a "executable": booting the produced kernel crashes
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
Comparing devel/powerpc64-binutils and its ld that works to
the bootstrapped tool's ld that does not. . .
[I do not yet know the stable/11 status for the below.]
>From the .meta file for using devel/powerpc64-binutils during
buildkernel:
CMD @/usr/local/powerpc64-freebsd/bin/ld -Bdynamic -T
/usr/src/sys/conf/ldscript.powerpc64 -pie --no-warn-mismatch --warn-common
--export-dynamic --dynamic-linker /red/herring -o kernel.full -X locore.o . .
.
leads to file for the kernel.full reporting:
ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD),
dynamically linked, interpreter /red/herring, not stripped
(-pie and "executable" go together, as expected.)
But from the .meta file for using the bootstrapped binutils during
buildkernel:
CMD @ld -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc64 -pie
--no-warn-mismatch --warn-common --export-dynamic --dynamic-linker
/red/herring -o kernel.full -X locore.o . . .
leads to file for the kernel.full reporting:
ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1
(FreeBSD), dynamically linked, interpreter /red/herring, not stripped
Note: -pie and "shared object" should not go together: it should be
"executable".
(The files from amd64 -> powerpc64 cross builds can be inspected
without involving any powerpc64 hardware.)
The shared object variant executes the wrong code instead of the start code
and does not boot (PowerMac G5 so-called "Quad Core" example test case).
This is because the start code is not at the beginning of the .text segment.
In other words instead of the expected:
Disassembly of section .text:
0000000000100120 <.__start> mfmsr r20
0000000000100124 <.__start+0x4> li r21,1
0000000000100128 <.__start+0x8> rldimi r20,r21,63,0
000000000010012c <.__start+0xc> mtmsrd r20
0000000000100130 <.__start+0x10> isync
. . .
as devel/powerpc64-binutils generates, the bootstrapped ld
produces instead:
Disassembly of section .text:
0000000000100160 <.__start-0x2130> std r2,40(r1)
0000000000100164 <.__start-0x212c> addis r2,r2,1
0000000000100168 <.__start-0x2128> addi r2,r2,-120
000000000010016c <.__start-0x2124> b 0000000000b32480 <.cpu_switch>
0000000000100170 <.__start-0x2120> std r2,40(r1)
0000000000100174 <.__start-0x211c> addis r2,r2,1
0000000000100178 <.__start-0x2118> addi r2,r2,-120
000000000010017c <.__start-0x2114> b 0000000000ae4148 <.sf_buf_alloc>
0000000000100180 <.__start-0x2110> std r2,40(r1)
0000000000100184 <.__start-0x210c> addis r2,r2,1
0000000000100188 <.__start-0x2108> addi r2,r2,-120
000000000010018c <.__start-0x2104> b 0000000000a88af8 <.vm_fault_hold>
. . .
0000000000102290 <.__start> mfmsr r20
0000000000102294 <.__start+0x4> li r21,1
0000000000102298 <.__start+0x8> rldimi r20,r21,63,0
000000000010229c <.__start+0xc> mtmsrd r20
00000000001022a0 <.__start+0x10> isync
. . .
yet code execution starts at 0000000000100160 instead of 0000000000102290
during booting.
As for the clang SRC_ENV_CONF file in use (failing "shared object"
context):
# more ~/src.configs/src.conf.powerpc64-clang-bootstrap.amd64-host
TO_TYPE=powerpc64
#
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=
WITH_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=
#
# buildkernel fails for sign mismatch on pointed-to types.
WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
As for the SRC_ENV_CONF file for a "executable" context:
# 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
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list