From owner-freebsd-hackers@freebsd.org Mon Oct 30 02:45:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5ACB8E52578 for ; Mon, 30 Oct 2017 02:45:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-161.reflexion.net [208.70.210.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B88C7029C for ; Mon, 30 Oct 2017 02:45:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22466 invoked from network); 30 Oct 2017 02:38:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Oct 2017 02:38:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 22:38:56 -0400 (EDT) Received: (qmail 1149 invoked from network); 30 Oct 2017 02:38:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Oct 2017 02:38:56 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 68E15EC9443; Sun, 29 Oct 2017 19:38:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> Date: Sun, 29 Oct 2017 19:38:54 -0700 Cc: freebsd-hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 02:45:44 -0000 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