From owner-freebsd-toolchain@FreeBSD.ORG Wed Apr 1 23:37:25 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E56E261 for ; Wed, 1 Apr 2015 23:37:25 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 470B6D3F for ; Wed, 1 Apr 2015 23:37:24 +0000 (UTC) Received: (qmail 18609 invoked from network); 1 Apr 2015 23:37:23 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Apr 2015 23:37:23 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 01 Apr 2015 19:37:23 -0400 (EDT) Received: (qmail 15022 invoked from network); 1 Apr 2015 23:37:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Apr 2015 23:37:22 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 31DE11C43AA; Wed, 1 Apr 2015 16:37:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64) From: Mark Millard In-Reply-To: Date: Wed, 1 Apr 2015 16:37:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF12D5F-F4A0-429E-AEAE-4AEF2D35FE31@dsl-only.net> References: To: Warner Losh X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Toolchain , FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:37:25 -0000 On 2015-Apr-1, at 02:49 PM, Warner Losh wrote: >> On Apr 1, 2015, at 2:44 PM, Mark Millard wrote: >>=20 >> Attempting to use CROSS_TOOLCHAIN=3Dpowerpc64-gcc on powerpc (non-64) = 11.0-CURRENT with TARGET_ARCH=3Dpowerpc64 gets: >>=20 >>> --- crti.o --- >>> gcc -O2 -pipe -I/usr/srcC/lib/csu/powerpc64/../common = -I/usr/srcC/lib/csu/powerpc64/../../libc/include -mlongcall -std=3Dgnu99 = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter = -Wcast-align -Wchar-subscripts -Winline -Wnested-externs = -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c = /usr/srcC/lib/csu/powerpc64/crti.S >>> ... >>> /usr/srcC/lib/csu/powerpc64/crti.S: Assembler messages: >>> /usr/srcC/lib/csu/powerpc64/crti.S:35: Error: junk at end of line, = first unrecognized character is `@' >>> /usr/srcC/lib/csu/powerpc64/crti.S:51: Error: junk at end of line, = first unrecognized character is `@' >>> *** [crti.o] Error code 1 >>>=20 >>=20 >>=20 >>=20 >> Read below only for analysis. >>=20 >>=20 >>=20 >> First I'll deal with the error messages. Then I'll deal with the = "gcc". >>=20 >> The lines of crti.S in question are: >>=20 >>> .quad .L._init,.TOC.@tocbase,0 >>> ... >>> .quad .L._fini,.TOC.@tocbase,0 >>=20 >> The error messages are because __powerpc64__ is not defined when = machine/asm.h is included so the wrong definition is used for = _ENTRY(=E2=80=A6): >=20 > The gcc port needs to be fixed, with changes fed upstream. The head/lib/csu/powerpc64/Makefile generated "gcc" as the command (see = above). That in turn ended up as using: /usr/bin/gcc , which is the = FreeBSD 4.2.1 system gcc. So no port was involved. That may be the (or a) problem: ${XCC} was not = being used. >>> #ifdef __powerpc64__ >>> ... >>> #define _ENTRY(name) \ >>> .section ".text"; \ >>> .p2align 2; \ >>> .globl name; \ >>> .section ".opd","aw"; \ >>> .p2align 3; \ >>> name: \ >>> .quad DOT_LABEL(name),.TOC.@tocbase,0; \ >>> .previous; \ >>> .p2align 4; \ >>> TYPE_ENTRY(name) \ >>> DOT_LABEL(name): >>> ... >>> #else /* !__powerpc64__ */ >>> #define _ENTRY(name) \ >>> .text; \ >>> .p2align 4; \ >>> .globl name; \ >>> .type name,@function; \ >>> name: >>> #define _END(name) >>> #endif /* __powerpc64__ */ >>=20 >> The (powerpc64 specific) Makefile may need to force a 64-bit usage = (-m64 ?), presuming that such is supported from the 32 bit environment. >=20 > Generally, we=E2=80=99ve not added those kinds of flags to the command = line. There=E2=80=99s many subtle issues in the tree trying to do = that=E2=80=A6 >=20 > Warner =46rom a powerpc (non-64) 11.0-CURRENT boot is the following supposed to = work by producing a powerpc64 appropriate result (no CROSS_TOOLCHAIN for = this question)?=20 make buildworld buildkernel KERNCONF=3DGENERIC64 TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64 The standard v4.2.1 /usr/bin/gcc in a powerpc context (non-64) for that = make command would produce files for TARGET_ARCH=3Dpowerpc unless the = command lines specified otherwise. Notably the build environment is picking powerpc64 specific paths when = appropriate, such as: lib/csu/powerpc64/Makefile so that specific Makefile is not likely to be used when powerpc64 = handling is inappropriate, even executed from from a powerpc (non-64) = context. A different path (and so a distinct Makefile) would be used for = KERNCONF=3DGENERIC TARGET_ARCH=3Dpowerpc . =3D=3D=3D Mark Millard markmi at dsl-only.net