There are two nearly 100% cpu usage instances of
powerpc64-unknown-freebsd13.0-ld , each with over
480 cpu minutes, one for clang.full and one for
lld.full . (amd64->powerpc64 cross build.)
The below shows the file system view of the status
after all that time: 0 size .full files.
# ls -ldTt
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full*
| head
-rw-r--r-- 1 root wheel 3071 Dec 30 00:30:02 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full.meta
-rw-r--r-- 1 root wheel 0 Dec 30 00:29:32 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full
# ls -ldTt
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full*
| head
-rw-r--r-- 1 root wheel 3071 Dec 30 00:30:02 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full.meta
-rw-r--r-- 1 root wheel 0 Dec 30 00:29:32 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full
Attaching to one of them with gdb shows
(I build ports optimized but with symbols generally):
(gdb) bt
#0 0x000000000035431d in ppc64_elf_inline_plt (info=<optimized out>) at
elf64-ppc.c:7473
#1 0x000000000032acb0 in ppc_before_allocation () at eelf64ppc_fbsd.c:370
#2 0x0000000000319651 in lang_process () at ldlang.c:7678
#3 0x00000000003208d8 in main (argc=<optimized out>, argv=<optimized out>) at
./ldmain.c:441
ppc64_elf_inline_plt does not return (finish
does not stop on its own).
Using step shows:
(gdb) step
7471 in elf64-ppc.c
(gdb)
7473 in elf64-ppc.c
(gdb)
7471 in elf64-ppc.c
(gdb)
7473 in elf64-ppc.c
. . .
Looking at the instruction level:
(gdb) display/i $pc
1: x/i $pc
=> 0x35431d <ppc64_elf_inline_plt+557>: jne 0x354310
<ppc64_elf_inline_plt+544>
(gdb) nexti
7471 in elf64-ppc.c
1: x/i $pc
=> 0x354310 <ppc64_elf_inline_plt+544>: mov 0x8(%r13),%r12
(gdb)
7473 in elf64-ppc.c
1: x/i $pc
=> 0x354314 <ppc64_elf_inline_plt+548>: mov %r12d,%eax
(gdb)
0x0000000000354317 7473 in elf64-ppc.c
1: x/i $pc
=> 0x354317 <ppc64_elf_inline_plt+551>: or $0x2,%eax
(gdb)
0x000000000035431a 7473 in elf64-ppc.c
1: x/i $pc
=> 0x35431a <ppc64_elf_inline_plt+554>: cmp $0x7a,%eax
(gdb)
0x000000000035431d 7473 in elf64-ppc.c
1: x/i $pc
=> 0x35431d <ppc64_elf_inline_plt+557>: jne 0x354310
<ppc64_elf_inline_plt+544>
(gdb)
7471 in elf64-ppc.c
1: x/i $pc
=> 0x354310 <ppc64_elf_inline_plt+544>: mov 0x8(%r13),%r12
(gdb)
7473 in elf64-ppc.c
1: x/i $pc
=> 0x354314 <ppc64_elf_inline_plt+548>: mov %r12d,%eax
(gdb)
0x0000000000354317 7473 in elf64-ppc.c
1: x/i $pc
=> 0x354317 <ppc64_elf_inline_plt+551>: or $0x2,%eax
(gdb)
0x000000000035431a 7473 in elf64-ppc.c
1: x/i $pc
=> 0x35431a <ppc64_elf_inline_plt+554>: cmp $0x7a,%eax
(gdb)
0x000000000035431d 7473 in elf64-ppc.c
1: x/i $pc
=> 0x35431d <ppc64_elf_inline_plt+557>: jne 0x354310
<ppc64_elf_inline_plt+544>
. . .
To do the experiment I built devel/freebsd-gcc9 based on:
( ports at -r520539 )
# svnlite diff /usr/ports/devel/freebsd-gcc9/
Index: /usr/ports/devel/freebsd-gcc9/Makefile
===================================================================
--- /usr/ports/devel/freebsd-gcc9/Makefile (revision 520539)
+++ /usr/ports/devel/freebsd-gcc9/Makefile (working copy)
@@ -53,6 +53,10 @@
--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
+.if ${TARGETARCH} == powerpc64
+CONFIGURE_ARGS+= --with-abi=elfv2
+.endif
+
ALL_TARGET= all-gcc
INSTALL_TARGET= install-gcc
(So I forced elfv2 for powerpc64.)
I'm also using WITHOUT_LIB32 to avoid the
the forced bss-plt that ends up involved:
It stops the build:
# svnlite diff /usr/src/share/mk/bsd.cpu.mk
Index: /usr/src/share/mk/bsd.cpu.mk
===================================================================
--- /usr/src/share/mk/bsd.cpu.mk (revision 356187)
+++ /usr/src/share/mk/bsd.cpu.mk (working copy)
@@ -421,7 +421,7 @@
# normal builds works when CROSS_BINUTILS_PREFIX and could be removed
# when LLD PowerPC 32 bit support is completed
.if defined(CROSS_BINUTILS_PREFIX)
-LD_BFD=${LOCALBASE}/bin/${CROSS_BINUTILS_PREFIX}-ld.bfd
+LD_BFD=${CROSS_BINUTILS_PREFIX}ld.bfd
.else
LD_BFD=${OBJTOP}/tmp/usr/bin/ld.bfd
.endif
(The above change used a working file path.)
I used:
# more ~/src.configs/src.conf.powerpc64-xtoolchain-gcc.amd64-host
GCCVERSION=9
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=13.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
WITHOUT_SYSTEM_LINKER=
#
WITH_LLVM_LIBUNWIND=
WITH_LIBCPLUSPLUS=
WITHOUT_LLD_BOOTSTRAP=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_LLVM_TARGET_ALL=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITHOUT_BINUTILS=
#WITH_PORT_BASE_BINUTILS=
# Note: LLDB fails to build (link).
WITHOUT_LLDB=
#
WITH_BOOT=
#
# Fails to build because of forced bss-plt use.
WITHOUT_LIB32=
#
LOADER_DEFAULT_INTERP=4th
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
#WERROR=
MALLOC_PRODUCTION=
#
# Avoid stripping but do not control host -g status as well:
DEBUG_FLAGS+=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#XCFLAGS+= -gdwarf-2
#
# For TO (so-called "cross") stages . . .
# So-called-cross via freebsd-gcc${GCCVERSION}@${TO_TYPE}
# TOOLS_TO_TYPE based on freebsd-gcc${GCCVERSION}@${TO_TYPE} related binutils.
. .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc${GCCVERSION}
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc${GCCVERSION}
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++${GCCVERSION}
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp${GCCVERSION}
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/size
#NO-SUCH:
XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-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
.endif
By contrast, cross-building powerpc64 using system-clang
and devel/binutils@powerpc64 ran to completion, as did
the default system-clang/lld use.
Using ELFv2 for devel/freebsd-gcc9 did avoid the
internal plt template error report that I got
earlier when targeting a ELFv1 context.
32-bit powerpc side note:
For 32-bit powerpc, the only combination to complete
buildworld buildkernel was system-clang with
devel/binutils@powerpc . The default system linker
failed with acl_nfs4.kld(.text+0x234): R_PPC_PLTREL24
reloc against local symbol. Using
devel/freebsd-gcc9@powerpc with devel/binutils@powerpc
resulted in forced bss-plt use stopping the build.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
