Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Oct 2017 00:23:56 -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:  <F6C5BBFB-C4E9-4E03-B1B6-576A2892F2A4@dsl-only.net>
In-Reply-To: <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@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> <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
[It is not as bad as I was thinking as far
as the --print-file-name output goes.]

On 2017-Oct-29, at 7:38 PM, Mark Millard <markmi at dsl-only.net> wrote:

> 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:
>=20
>=20
> These first --print-file-name
> outputs are from on my
> amd64 -> powerpc64 cross build
> environment:
>=20
> # which clang
> /usr/bin/clang
>=20
> # clang --print-file-name=3Dcrti.o
> /usr/lib/crti.o
> # clang -m32 --print-file-name=3Dcrti.o
> /usr/lib32/crti.o
>=20
> # clang --print-file-name=3DcrtbeginS.o
> /usr/lib/crtbeginS.o
> # clang -m32 --print-file-name=3DcrtbeginS.o
> /usr/lib32/crtbeginS.o
>=20
> # 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
>=20
> # 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
>=20
> (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.)
>=20
> 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 .
>=20
> # gcc7 --print-file-name=3Dcrti.o
> /usr/lib/crti.o
> # gcc7 -m32 --print-file-name=3Dcrti.o
> /usr/lib/crti.o
>=20
> # 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
>=20
> (Odd mix of system and gcc7 materials above?
> Note the lack of -m32 having a distinct path
> as well.)
>=20
> On my (clang built) powerpc64 environment
> powerpc64-unknown-freebsd12.0-gcc ends
> up with different results:
>=20
> # clang --print-file-name=3Dcrti.o
> /usr/lib/crti.o
> # clang -m32 --print-file-name=3Dcrti.o
> /usr/lib32/crti.o
>=20
> # clang --print-file-name=3DcrtbeginS.o
> /usr/lib/crtbeginS.o
> # clang -m32 --print-file-name=3DcrtbeginS.o
> /usr/lib32/crtbeginS.o
>=20
> # 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
>=20
> # 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
>=20
>=20
> (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].)
>=20
> # gcc7 --print-file-name=3Dcrti.o
> /usr/lib/crti.o
> # gcc7 -m32 --print-file-name=3Dcrti.o
> /usr/lib/../lib32/crti.o
>=20
> # 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=

>=20
>=20
> (Again the odd(?) system vs. gcc mix for gcc7.
> But the -m32 path is distinct in this context.)
>=20
> 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.)
>=20
>=20
>=20
> 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:
>=20
> # find /usr/local/ -name "crtbeginS.o" -print | more                   =
                                                                         =
               =20
> /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o
>=20
> (This also confirms that lack of a . . ./32/crtbeginS.o
> for the amd64 native gcc7 compiler.)
>=20
> 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.


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/us=
r/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.

But these files show the r30 problem and the
inlining.


You may want to skip the following detail.

# 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/po=
werpc64/crtn.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po=
werpc64/crtn.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po=
werpc64/crti.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po=
werpc64/crti.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/lib/csu/powerpc/crtn.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/lib/csu/powerpc/crtn.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/lib/csu/powerpc/crti.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/lib/csu/powerpc/crti.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li=
b/crti.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li=
b/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/cs=
u/crtbeginS.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs=
u/crtendS.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs=
u/crtendS.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs=
u/crtbeginS.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/gnu/lib/csu/crtbeginS.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/gnu/lib/csu/crtendS.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/gnu/lib/csu/crtbeginS.o.meta
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us=
r/src/gnu/lib/csu/crtendS.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li=
b/crtbeginS.o
=
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li=
b/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=3Dpowerpc -m32
-DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3D3
-g0 -DCRT_BEGIN -DCRTSTUFFS_O
-DSHARED -fpic
-c -o crtbeginS.o
/usr/src/contrib/gcc/crtstuff.c


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



=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?F6C5BBFB-C4E9-4E03-B1B6-576A2892F2A4>