Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Jan 2017 08:36:22 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [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
Message-ID:  <bug-215821-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215821

            Bug ID: 215821
           Summary: head -r311147's ld for TARGET_ARCH=3Dpowerpc64 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@FreeBSD.org
          Reporter: markmi@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=20
TO_TYPE=3Dpowerpc64
#
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
WITH_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
#
# buildkernel fails for sign mismatch on pointed-to types.
WERROR=3D
MALLOC_PRODUCTION=3D
#
WITH_DEBUG_FILES=3D


As for the SRC_ENV_CONF file for a "executable" context:

# 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

--=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-215821-8>