Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using?

[Mark Millard]

I've found a way in which crti.o and crtbeginS.o and
the like are broken for cross builds such as
amd64 -> powerpc64 based builds:


These first --print-file-name
outputs 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.)

It looks like the path oddities cause lack of dining
any crti.o or crtbeginS.o or the like, which causes
the compiler/linker to work differently from
different materials that are internal to
devel/powerpc64-gcc .

# 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?
Note the lack of -m32 having a distinct path
as well.)

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.
But the -m32 path is distinct in this context.)

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?
(nothing found.)



Note that /usr/local/. . . does not even have
the likes of crti.o or crtbeginS.o (or so on)
for devel/powerpc64-gcc to use in cross builds:

# 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.)

It appears that devel/powerpc64-gcc used for cross
builds is generating what would otherwise be
crti.o and crtbeginS.o content on the fly as needed
during its compiles: there are none around to
use the contents of.

===
Mark Millard
markmi at dsl-only.net