I should have explicitly said that the buildworld/buildkernel used powerpc64-gcc to do the build and included the src.conf. I should have shown the FreeBSD version for the latest example as well:

# freebsd-version -ku; uname -aKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r293632M: Sun Jan 10 12:47:56 PST 2016     markmi@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG  powerpc 1100093 1100093

make.conf empty.

src.conf:

TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
FROM_TYPE=powerpc64
TOOLS_FROM_TYPE=${FROM_TYPE}
VERSION_CONTEXT=11.0
#
KERNCONF=GENERIC64vtsc-NODEBUG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
#
# 1 thing that fails to build if attempted via gcc variants:
WITHOUT_CLANG_EXTRAS=
#
WITH_FAST_DEPEND=
WITH_LIBCPLUSPLUS=
WITH_LIB32=
WITH_BOOT=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_LLDB=
#
WITHOUT_GCC=
WITHOUT_GNUCXX=
#
NO_WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG=
WITH_DEBUG_FILES=
#
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils...
#
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}-portbld-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-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
.if ${.MAKE.LEVEL} == 0
CC=/usr/local/bin/gcc49
CXX=/usr/local/bin/g++49
CPP=/usr/local/bin/cpp49
.export CC
.export CXX
.export CPP
.endif
.if ${.MAKE.LEVEL} == 0
AS=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/as
AR=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ar
LD=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ld
NM=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/nm
OBJCOPY=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objcopy
OBJDUMP=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objdump
RANLIB=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ranlib
SIZE=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/size
#NO-SUCH: STRINGS=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/strings
STRINGS=/usr/local/bin/strings
.export AS
.export AR
.export LD
.export NM
.export OBJCOPY
.export OBJDUMP
.export RANLIB
.export SIZE
.export STRINGS
.endif

From a list exchange:

On 2017-Oct-28, at 5:03 PM, Justin Hibbits <chmeeedalf at gmail.com> wrote:

On Oct 28, 2017 17:08, "Mark Millard" <markmi at dsl-only.net> wrote:
powerpc64 and powerpc have very different stack handling
rules for FreeBSD. As an example, powerpc does not require
red-zones for signal handling in the kernel but powerpc64
does.

For lib32 support, what ABI is the powerpc code supposed
to follow in the powerpc64 environment? What style of
stack handling (and related register usage) is supposed
to be in use? If it is distinct from powerpc native's
ABI, what documentation should be looked at for the ABI?
END MILLARD

PowerPC via lib32 should be using the 32-bit svr4 ABI. If you see any discrepancy in that, it's a bug that needs fixed.
END HIBBITS

MILLARD again:

Then I expect that the reason that devel/powerpc64-gcc
based buildworld's make a lib32 that fails in code that
is from /usr/lib32/crtbeginS.o is because
/usr/lib32/crtbeginS.o ends up  not having the right
ABI involved and, so, misuses at least one register.

(I've not worked out if there is any special transition from
one ABI to the other (and later back) that is needed vs. not.
But the red-zoning for powerpc64 should be more than sufficient
for powerpc code that does not require it.)

An interesting point is:
(all on a powerpc64 FreeBSD head -r324071 system)

# clang -dumpmachine -m32
powerpc-unknown-freebsd12.0

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine -m32
powerpc64-unknown-freebsd12.0

# gcc7 -dumpmachine -m32
powerpc64-portbld-freebsd12.0

# clang -dumpmachine
powerpc64-unknown-freebsd12.0

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine
powerpc64-unknown-freebsd12.0

# gcc7 -dumpmachine
powerpc64-portbld-freebsd12.0

(But I'm not sure that these always reflect
ABI variations in code generated.)

I wonder if for gcc it takes a separate compiler
to have powerpc-unknown-freebsd12.0 (intending
to imply the FreeBSD 32-bit ABI is in use).


bugzilla 206123 should probably have notes added about the
probable ABI mismatch in /usr/lib32/crtbeginS.o. I may add
this whole message but someone with better background
information may able to submit more specific material.

At this point I do not know how to control what ABI code
is generated by devel/powerpc64-gcc in what becomes
/usr/lib32/crtbeginS.o (or how other code interfaces with
crtbeginS.o code).

Its been a long time since I tried other gcc variations
but all of them had the issue when I did try.

(In reply to Mark Millard from comment #2)

I wrote:

I wonder if for gcc it takes a separate compiler
to have powerpc-unknown-freebsd12.0 (intending
to imply the FreeBSD 32-bit ABI is in use).

END

(It may be that I should have stuck a "modern"
in the wording, given that gcc 4.2.1 supported
building a lib32 that worked.)

If it does take a separate gcc compiler to have
powerpc-unknown-freebsd12.0 with the FreeBSD
32-bit ABI, then in order to support building
lib32 might require a devel/powerpc-gcc port
if a pre-defined way to build a gcc-based lib32
is to be supported via ports mixed with the
FreeBSD build system.

Otherwise buidlworld via devel/powerpc64-gcc
may just want to always use WITHOUT_LIB32= .

But I'm not aware of the FreeBSD build environment
being set up to have a distinct compiler to target
lib32 code.

Based on some amd64 -> powerpc64 and amd64 -> powerpc
buildworld buildkernel directory trees. . .

Note the <.init. .  .> material and its use of r30
when devel/powerpc64-gcc builds lib32's crtbeginS.o :

# /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/tmp/usr/bin/objdump -d --prefix-address /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/lib32/crtbeginS.o | grep r30
0000000c <__do_global_dtors_aux+0xc> stw     r30,24(r1)
00000010 <__do_global_dtors_aux+0x10> mflr    r30
0000001c <__do_global_dtors_aux+0x1c> lwz     r28,0(r30)
00000038 <__do_global_dtors_aux+0x38> lwz     r9,0(r30)
00000044 <__do_global_dtors_aux+0x44> lwz     r9,0(r30)
00000050 <__do_global_dtors_aux+0x50> lwz     r29,0(r30)
000000a4 <__do_global_dtors_aux+0xa4> lwz     r30,-8(r11)
000000c4 <call___do_global_dtors_aux+0x14> stw     r30,8(r1)
000000d8 <call___do_global_dtors_aux+0x28> lwz     r30,-8(r11)
000000f0 <frame_dummy+0xc> stw     r30,8(r1)
000000f4 <frame_dummy+0x10> mflr    r30
00000104 <frame_dummy+0x20> lwz     r3,0(r30)
00000114 <frame_dummy+0x30> lwz     r9,0(r30)
00000124 <frame_dummy+0x40> lwz     r30,-8(r11)
0000013c <frame_dummy+0x58> lwz     r30,-8(r11)
00000158 <call_frame_dummy+0xc> stw     r30,8(r1)
0000015c <call_frame_dummy+0x10> mflr    r30
0000017c <call_frame_dummy+0x30> lwz     r30,-8(r11)
00000000 <.init> lwz     r3,0(r30)
00000010 <.init+0x10> lwz     r9,0(r30)

It is the .init code and its use of r30 that is
directly crashing. (There could be more wrong.)

By contrast there is no such <.init. . .> r30 material
when gcc 4.2.1 does the lib32 build (clang built gcc
4.2.1 here):

# /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/tmp/usr/bin/objdump -d --prefix-address /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/tmp/usr/lib/crtbeginS.o | grep r30
0000000c <__do_global_dtors_aux+0xc> stw     r30,24(r1)
00000010 <__do_global_dtors_aux+0x10> mflr    r30
0000001c <__do_global_dtors_aux+0x1c> lwz     r28,0(r30)
00000038 <__do_global_dtors_aux+0x38> lwz     r0,0(r30)
00000044 <__do_global_dtors_aux+0x44> lwz     r9,0(r30)
00000050 <__do_global_dtors_aux+0x50> lwz     r29,0(r30)
000000a0 <__do_global_dtors_aux+0xa0> lwz     r30,-8(r11)
000000e8 <frame_dummy+0xc> stw     r30,8(r1)
000000ec <frame_dummy+0x10> mflr    r30
000000fc <frame_dummy+0x20> lwz     r3,0(r30)
0000010c <frame_dummy+0x30> lwz     r0,0(r30)
00000128 <frame_dummy+0x4c> lwz     r30,-8(r11)

And the .init is very simple:

# /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/tmp/usr/bin/objdump -d --prefix-address /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/tmp/usr/lib/crtbeginS.o | grep init
Disassembly of section .init:
00000000 <.init> bl      00000000 <.init>

compared to the .init that devel/powerpc64-gcc
generated:

# /usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/tmp/usr/bin/objdump -d --prefix-address /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/lib32/crtbeginS.o | grep init
Disassembly of section .init:
00000000 <.init> lwz     r3,0(r30)
00000004 <.init+0x4> lwz     r9,0(r3)
00000008 <.init+0x8> cmpwi   cr7,r9,0
0000000c <.init+0xc> beq-    cr7,00000024 <__do_global_dtors_aux+0x24>
00000010 <.init+0x10> lwz     r9,0(r30)
00000014 <.init+0x14> cmpwi   cr7,r9,0
00000018 <.init+0x18> beq-    cr7,00000024 <__do_global_dtors_aux+0x24>
0000001c <.init+0x1c> mtctr   r9
00000020 <.init+0x20> bctrl


Compared to the devel/powerpc64-gcc lib32's crtbeginS.o
below all the following have no r30 use in the gcc 4.2.1
output (but the routines do exist for the gcc 4.2.1
output):

000000c4 <call___do_global_dtors_aux+0x14> stw     r30,8(r1)
000000d8 <call___do_global_dtors_aux+0x28> lwz     r30,-8(r11)
00000158 <call_frame_dummy+0xc> stw     r30,8(r1)
0000015c <call_frame_dummy+0x10> mflr    r30
0000017c <call_frame_dummy+0x30> lwz     r30,-8(r11)
00000000 <.init> lwz     r3,0(r30)
00000010 <.init+0x10> lwz     r9,0(r30)

I've figured out the mismatch involved and, so,
why/how lib32 fails for devel/powerpc64-gcc based
builds: the .init code generation for
devel/powerpc64-gcc is tied to the glibc crti.S
for powerpc and that does not match what FreeBSD
has for the interface between the two parts.

As of 6 years ago or so glibc has code like (I'm
only dealing with the init side of things as an
example):

.section .init,"ax",@progbits
stwu r1, -16(r1)
. . .
bcl 29,31,.LMAGIC_LABEL
.LMAGIC_LABEL:
mflr r30
addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@ha
addi  r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@l
. . . (some pre-init function code) . . .

that comes before code that is from frame_dummy
and __do_global_ctors_aux (that are from
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c ).

The code generated for frame_dummy and
__do_global_ctors_aux expects r30 to already
be set up for _GLOBAL_OFFSET_TABLE_ related
use by the kind of code that I showed above.


Instead FreeBSD has for powerpc just:
(things are configured for devel/powerpc64-gcc
to use it)

#include <machine/asm.h>
__FBSDID("$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 11:34:58Z kib $");

        .section .init,"ax",@progbits
        .align  2
        .globl  _init
        .type   _init,@function
_init:
        stwu 1,-16(1)
        mflr 0
        stw 31,12(1)
        stw 0,20(1)
        mr 31,1

The overall result ends up being (from
an example .so):

0000214c <_init> stwu    r1,-16(r1)
00002150 <_init+0x4> mflr    r0
00002154 <_init+0x8> stw     r31,12(r1)
00002158 <_init+0xc> stw     r0,20(r1)
0000215c <_init+0x10> mr      r31,r1
(The above is the FreeBSD crti.S code.)
(Note the lack of initialization of r30
to the _GLOBAL_OFFSET_TABLE_ related value.)

(The below is the crtstuff.c frame_dummy code
inlined in a way that the function prolog code
is not present here.)
(Note the dependence on r30 having already been
initialized.)
00002160 <_init+0x14> lwz     r3,-712(r30)
00002164 <_init+0x18> lwz     r9,0(r3)
00002168 <_init+0x1c> cmpwi   cr7,r9,0
0000216c <_init+0x20> beq-    cr7,00002184 <_init+0x38>
00002170 <_init+0x24> lwz     r9,-16(r30)
00002174 <_init+0x28> cmpwi   cr7,r9,0
00002178 <_init+0x2c> beq-    cr7,00002184 <_init+0x38>
0000217c <_init+0x30> mtctr   r9
00002180 <_init+0x34> bctrl

(The below is the crtstuff.c __do_global_ctors_aux
loop code but inlined. . .)
00002184 <_init+0x38> lwz     r29,-36(r30)
00002188 <_init+0x3c> lwzu    r9,-4(r29)
0000218c <_init+0x40> cmpwi   cr7,r9,-1
00002190 <_init+0x44> beq-    cr7,000021a8 <_init+0x5c>
00002194 <_init+0x48> mtctr   r9
00002198 <_init+0x4c> bctrl
0000219c <_init+0x50> lwzu    r9,-4(r29)
000021a0 <_init+0x54> cmpwi   cr7,r9,-1
000021a4 <_init+0x58> bne+    cr7,00002194 <_init+0x48>

(The rest of the .init code follows.)
000021a8 <_init+0x5c> lwz     r11,0(r1)
000021ac <_init+0x60> lwz     r0,4(r11)
000021b0 <_init+0x64> mtlr    r0
000021b4 <_init+0x68> lwz     r31,-4(r11)
000021b8 <_init+0x6c> mr      r1,r11
000021bc <_init+0x70> blr

The way the compiler's source code is structured
and works it looks to me like the crti.S used needs
to have the initialization code for r30: it must
provide that part of the function prolog code as
well.

For reference,

devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c

uses globals that drive the r30 use in the
code being put in the .init area. . .

In frame_dummy:

__JCR_LIST__
_Jv_RegisterClasses

(with some testing for weak references).

In __do_global_ctors_aux:

__CTOR_END__


Also: CRT_CALL_STATIC_FUNCTION use
for frame_dummy and for __do_global_ctors_aux
avoids the function prolog code of either
being put in the .init code.

I've looked an a copy of the 1995 Sun Microsystems
PPC SYSVR4 ABI document and its table 3-3 about
processor register usage is not explicit about
a specific register being used relative to
_GLOBAL_OFFSET_TABLE_ handling.

There are examples that say things like:

Assumes GOT pointer in r31

but as far as I can tell no place requires that.
In fact there is wording like:

Combining the offset with the global offset table address in a general register (for example, r31 loaded in the sample prologue in Figure 3-33) gives the absolute address of the table entry holding the desired address.

which explicitly indicates "in a general register".

It appears that crti.S type code for share
libraries requires a local convention for
the choice of register that the compiler and
library must agree on.

So r30 looks to be a valid choice but possibly
compiler specific for a FreeBSD context.

But there may be a reason to stick with r30. . .

Looking in Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf
reports that:

Under the Secure-PLT ABI, when using the Position-Independent Code (PIC) addressing model, register r30 is used (by convention between compiler & link editor) in nonleaf functions to hold the Global Offset Table (GOT) pointer.

. . .

Using r30 to hold the address of the _GLOBAL_OFFSET_TABLE_ symbol is the current convention used
by the compiler and link-editor and is only required for nonleaf routines which use the PIC addressing model. Leaf routines or code not using the PIC addressing model may use any available unreserved general-purpose register to hold the address of the _GLOBAL_OFFSET_TABLE_ symbol.

. . .

The PIC call stub sequence requires that the compiler ensure that the register used to hold the _GLOBAL_OFFSET_TABLE_ pointer is set before any calls are made from the PLT. The current convention between the compiler and link editor is that r30 be used for this purpose. This is a change from the BSS-PLT ABI which only required GOT addressing to access static storage.

. . .

For non-PIC code, r30 will not hold the GOT pointer; so the stubs must be different, as shown in the following implementation.

. . .

Note: This ABI does not require a fixed GOT register, or even one register used throughout a binary. Non-PIC code does not set the _GLOBAL_OFFSET_TABLE_ pointer and does not need to reserve a register for that purpose. Code under the PIC addressing model that accesses static storage or calls nonlocal functions will need a register to hold the _GLOBAL_OFFSET_TABLE_ pointer. However, leaf functions or functions that only call other functions which are static (@local) may use any general-purpose register within the constraints for the existing ABI.



By contrast Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf
does not say much about r30 use, including not specifying
the Secure-PLT ABI material.

The referenced documents are examples of:

Power Architecture® 32-bit Application Binary Interface Supplement 1.0

documents published in, for example, 2011 (Power.org
copyright for that date but various other copyrights
for various earlier dates).

(In reply to Mark Millard from comment #7)

I was not explicit but it appears that the crti.S
like code (but targeting devel/powerpc64-gcc code
generation conventions relative to r30 use) and
the .init material need to together treat r30 as
non-volatile overall in order to match the ABI
requirements for such.

--print-file-name seems to show some
odd differences among clang ,
powerpc64-unknown-freebsd12.0-gcc ,
and gcc7 for the likes of crti.o
and crtbeginS.o . For cross builds
powerpc64-unknown-freebsd12.0-gcc
seems to be broken in this area.

These first ones are from on
my amd64 -> powerpc64 cross build
environment:

# which clang
/usr/bin/clang

# clang --print-file-name=crti.o
/usr/lib/crti.o
# clang -m32 --print-file-name=crti.o
/usr/lib32/crti.o

# clang --print-file-name=crtbeginS.o
/usr/lib/crtbeginS.o
# clang -m32 --print-file-name=crtbeginS.o
/usr/lib32/crtbeginS.o

# powerpc64-unknown-freebsd12.0-gcc --print-file-name=crti.o
crti.o
# powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=crti.o
crti.o

# powerpc64-unknown-freebsd12.0-gcc --print-file-name=crtbeginS.o
crtbeginS.o
# powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=crtbeginS.o                                                                                                                     crtbeginS.o

(Note the lack of path prefixes above: they are not
explicitly from /usr/local/lib/. . . for some reason.
System ones would not be appropriate. Note that nothing
differentiates -m32 use.)

# gcc7 --print-file-name=crti.o
/usr/lib/crti.o
# gcc7 -m32 --print-file-name=crti.o
/usr/lib/crti.o

# gcc7 --print-file-name=crtbeginS.o
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o
# gcc7 -m32 --print-file-name=crtbeginS.o                                                                                                                                                  /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o

(Odd mix of system and gcc7 materials above?)

On my (clang built) powerpc64 environment
powerpc64-unknown-freebsd12.0-gcc ends
up with different results:

# clang --print-file-name=crti.o
/usr/lib/crti.o
# clang -m32 --print-file-name=crti.o
/usr/lib32/crti.o

# clang --print-file-name=crtbeginS.o
/usr/lib/crtbeginS.o
# clang -m32 --print-file-name=crtbeginS.o
/usr/lib32/crtbeginS.o

# powerpc64-unknown-freebsd12.0-gcc --print-file-name=crti.o
/usr/lib/crti.o
# powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=crti.o
/usr/lib/../lib32/crti.o

# powerpc64-unknown-freebsd12.0-gcc --print-file-name=crtbeginS.o
/usr/lib/crtbeginS.o
# powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=crtbeginS.o
/usr/lib/../lib32/crtbeginS.o


(Path prefixes present above. Using system ones would
not be likely to match using /usr/local/lib/. . . ones
from a cross build environment. But to have builds
from both hosts be equivalent would require the hosts
to use the same files [by content].)

# gcc7 --print-file-name=crti.o
/usr/lib/crti.o
# gcc7 -m32 --print-file-name=crti.o
/usr/lib/../lib32/crti.o

# gcc7 --print-file-name=crtbeginS.o
/usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/crtbeginS.o
# gcc7 -m32 --print-file-name=crtbeginS.o
/usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/32/crtbeginS.o


(Again the odd(?) system vs. gcc mix for gcc7.)

Does devel/powerpc64-gcc for cross builds require
taking control of the crti.o and crtbeginS.o (and
. . .) generation to force a match to what
self-hosted would have on the target architecture?

(In reply to Mark Millard from comment #9)

Looking around shows that for the cross
build context devel/powerpc64-gcc does
not even have external files for crti.o
or crtbeginS.o or the like to copy from.

Instead it either has internal copies
or is doing on the fly generation of the
content.

# find /usr/local/ -name "crtbeginS.o" -print | more                                                                       
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o

(This also confirms that lack of a . . ./32/crtbeginS.o
for the amd64 native gcc7 compiler. The same path
repeating for -m32 was no accident on amd64.)

# find /usr/local/ -name "crti.o" -print | more                                                                                                                                       

(nothing found.) So looking for *crt*.o:

# find /usr/local/ -name "*crt*.o" -print | more
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtend.o
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtendS.o
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbegin.o

devel/powerpc64-gcc has none.

Things only work when the on-the-fly/internal code
it generates/uses happens to match well with its
environment. The glibc tie for r30 use for GOT
is not a match for FreeBSD.

(In reply to Mark Millard from comment #9)

FYI: despite the lack of a path prefix
from --print-file-name . . .

It appears to me that what appears in the
lib32 .so.* files for .init is from:

/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/gnu/lib/csu/crt*.o

content.

Apparently without the path prefix it is looking
based on other path specifications to find something.
It just can not report later what it actually found
and used for the file requested.


So, not as bad as I was thinking earlier.

The problem is based on processing FreeBSD
source code, including /usr/src/contrib/gcc/crtstuff.c
and /usr/src/lib/csu/powerpc64/crt[in].S :

# find /usr/src/* /usr/obj/powerpc64vtsc_xtoolchain-gcc/ -name "*crt[in]*.*" -print | more
. . .
/usr/src/lib/csu/powerpc64/crti.S
/usr/src/lib/csu/powerpc64/crtn.S
. . .
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/powerpc64/crtn.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/powerpc64/crtn.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/powerpc64/crti.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/powerpc64/crti.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crtn.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crtn.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/lib/crti.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/lib/crtn.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/lib32/crti.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/lib32/crtn.o


# find /usr/src/* /usr/obj/powerpc64vtsc_xtoolchain-gcc/ -name "*crt[be]*S.*" -print | more
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/csu/crtbeginS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/csu/crtendS.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/csu/crtendS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/csu/crtbeginS.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/gnu/lib/csu/crtbeginS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/gnu/lib/csu/crtendS.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/gnu/lib/csu/crtbeginS.o.meta
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/usr/src/gnu/lib/csu/crtendS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/lib/crtbeginS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/lib/crtendS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/lib32/crtendS.o
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/lib32/crtbeginS.o

Showing -m32 examples:

-DCOMPAT_32BIT -mcpu=powerpc -m32
-DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3
-g0 -DCRT_BEGIN -DCRTSTUFFS_O
-DSHARED -fpic
-c -o crtbeginS.o
/usr/src/contrib/gcc/crtstuff.c


-DCOMPAT_32BIT -mcpu=powerpc -m32
-DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3
-g0 -DCRT_END -DCRTSTUFFS_O
-DSHARED -fpic
-o crtendS.o
/usr/src/contrib/gcc/crtstuff.c

(I omitted many command line options.)

It just appears that for devel/powerpc64-gcc and the
like crt[in].S analogous content but that is matched
to the category of compiler's register usage specifics
is needed (for issues the ABI does not make unique
across compilers but that still have conventions).

Other issues associated with the ABI updates for the
powerpc families prevents getting as far as testing
this again (based on modern devel/freebsd-gcc9@powerpc64
usage). Builds abort or hang (gnu ld stuck in a loop).

There is also the -msvr4-struct-return vs.
-maix-struct-return issue, where FreeBSD and its clang
(addicentally?) changed but gcc* is the old way,
leading to an ABI mismatch even with lib32 not
involved.

It may be some time before things are back to the
point of allowing lib32 handling to be checked for
devel/freebsd-gcc*@powerpc64 based buildworld's.