From owner-freebsd-ppc@freebsd.org Mon Jan 18 02:13:26 2016 Return-Path: Delivered-To: freebsd-ppc@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 CD19EA86827 for ; Mon, 18 Jan 2016 02:13:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 83A7115C2 for ; Mon, 18 Jan 2016 02:13:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1128 invoked from network); 18 Jan 2016 02:13:33 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Jan 2016 02:13:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 17 Jan 2016 21:13:25 -0500 (EST) Received: (qmail 8293 invoked from network); 18 Jan 2016 02:13:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 18 Jan 2016 02:13:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 384AE1C43D3; Sun, 17 Jan 2016 18:13:18 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Anyone have a clue why powerpc64-gcc produces the following in /usr/lib32/crtbeginS.o ? Date: Sun, 17 Jan 2016 18:13:22 -0800 Message-Id: To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 02:13:26 -0000 Does anyone have a clue why lang/powerpc64-gcc produces the following in = /usr/lib32/crtbeginS.o when WITH_LIB32=3D is part of what is attempted = via a cross compile? Anyone that does want to enlighten me on why? # /usr/local/powerpc64-freebsd/bin/objdump -d /usr/lib32/crtbeginS.o . . . Disassembly of section .init: 00000000 <.init>: 0: 80 7e 00 00 lwz r3,0(r30) 4: 81 23 00 00 lwz r9,0(r3) 8: 2f 89 00 00 cmpwi cr7,r9,0 c: 41 9e 00 18 beq cr7,24 <__do_global_dtors_aux+0x24> 10: 81 3e 00 00 lwz r9,0(r30) 14: 2f 89 00 00 cmpwi cr7,r9,0 18: 41 9e 00 0c beq cr7,24 <__do_global_dtors_aux+0x24> 1c: 7d 29 03 a6 mtctr r9 20: 4e 80 04 21 bctrl (Bug 206123)? When the code is extracted and substituted the zero = offsets from R30 are replaced, such as lwz r3,-11432(r30) . . . lwz r9,-856(r30) for the matching pair of (R30)'s in _init in the produced = /usr/lib32/libc.so.7 (position after installation). Darwin's 32-bit ABI did reserve R30 for the frame pointer. But did = anything else for some powerpc 32-bit contexts? Why would = lang/powerpc64-gcc be generating Darwin-32-bit-ABI code here (if that is = what the above is)? gcc 4.2.1 instead produces: Disassembly of section .init: 00000000 <.init>: 0: 48 00 00 01 bl 0 <.init> My clang 3.8.0 based buildworld experiment for TARGET_ARCH=3Dpowerpc = (non-64) got the same result as gcc 4.2.1 for this. [Part of the reason that the clang 3.8.0 based buildworld completed is = that -msoft-float support has recently been added for "ppc32", allowing = libstand to not stop the build. "ppc64" does not have such yet: use of = -msoft-float on the command line stops the compile with a message in = clang 3.8.0 .] =3D=3D=3D Mark Millard markmi at dsl-only.net