Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Oct 2017 19:38:54 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        Justin Hibbits <chmeeedalf@gmail.com>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using?
Message-ID:  <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net>
In-Reply-To: <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net>
References:  <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <CAHSQbTD8RGw6FBA0Uz2vrgOndJcvuLQZjTe_rsOSmqf9UMca=g@mail.gmail.com> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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=3Dcrti.o
/usr/lib/crti.o
# clang -m32 --print-file-name=3Dcrti.o
/usr/lib32/crti.o

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

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

# powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o
crtbeginS.o
# powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.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=3Dcrti.o
/usr/lib/crti.o
# gcc7 -m32 --print-file-name=3Dcrti.o
/usr/lib/crti.o

# gcc7 --print-file-name=3DcrtbeginS.o
/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o
# gcc7 -m32 --print-file-name=3DcrtbeginS.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=3Dcrti.o
/usr/lib/crti.o
# clang -m32 --print-file-name=3Dcrti.o
/usr/lib32/crti.o

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

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

# powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o
/usr/lib/crtbeginS.o
# powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.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=3Dcrti.o
/usr/lib/crti.o
# gcc7 -m32 --print-file-name=3Dcrti.o
/usr/lib/../lib32/crti.o

# gcc7 --print-file-name=3DcrtbeginS.o
/usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/crtbeginS.o
# gcc7 -m32 --print-file-name=3DcrtbeginS.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                     =
                                                                         =
             =20
/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.

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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CF73C8D-19A7-407C-9538-6D02F8FBBD1C>