From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 10 21:21:20 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A2B7317 for ; Fri, 10 Apr 2015 21:21:20 +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 D3D6097E for ; Fri, 10 Apr 2015 21:21:19 +0000 (UTC) Received: (qmail 21348 invoked from network); 10 Apr 2015 21:21:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2015 21:21:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 10 Apr 2015 17:21:18 -0400 (EDT) Received: (qmail 1659 invoked from network); 10 Apr 2015 21:21:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Apr 2015 21:21:18 -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 6F3BDB1E001; Fri, 10 Apr 2015 14:21:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE) From: Mark Millard In-Reply-To: Date: Fri, 10 Apr 2015 14:21:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8F0A9A-593E-4FEE-8F01-20799DE946B2@dsl-only.net> <7049E178-9FC8-4590-95AD-F80A2BBC3F01@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:21:20 -0000 I had written: > So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now = based on the notation >=20 > -Wl,-m -Wl,elf32ppc_fbsd >=20 > which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. Based on the system/normal gcc 4.2.1 context I=E2=80=99ve successfully = updated/rebuilt/booted: A) powerpc64 10.1-STABLE -r281235 (self updated from my prior snapshot) B) powerpc64 11.0-CURRENT -r281236 C) powerpc 11.0-CURRENT -r281236 (with -r281243 applied to fix register = save/restore) (B) and (C) were built from (A)=E2=80=99s context (using a separate = 11.0-CURRENT svn-based source tree) and DESTDIR used to installkernel = and installworld to other SSD=E2=80=99s that were being updated. The powerpc64-xtoolchain-gcc experimental update on a different PowerMac = G5 G5 did okay as far as it got based on the notation. But it did not = complete. It will be a while before I research the following references = to compiler support routines for restoring various general purpose = registers. > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/src/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/src/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE -m > 32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -Wl,-m -Wl,elf32ppc_fbsd -Wl,-m -Wl,elf32ppc_fbsd -o = boot1.elf boot1.o ashldi3.o syncicache.o=20 got: > boot1.o: In function `__puts': > boot1.c:(.text+0xf4): undefined reference to `_restgpr_28_x' > boot1.o: In function `__printf': > boot1.c:(.text+0x4fc): undefined reference to `_restgpr_24_x' > boot1.o: In function `ofw_getprop': > boot1.c:(.text+0x628): undefined reference to `_restgpr_31_x' > boot1.o: In function `ofw_close': > boot1.c:(.text+0x694): undefined reference to `_restgpr_31_x' > boot1.o: In function `dskread': > boot1.c:(.text+0x79c): undefined reference to `_restgpr_25_x' > boot1.o: In function `fsread': > boot1.c:(.text+0xce4): undefined reference to `_restgpr_14_x' > boot1.o: In function `domount': > boot1.c:(.text+0xdb8): undefined reference to `_restgpr_28_x' > boot1.o: In function `ofw_write.constprop.2': > boot1.c:(.text+0xe40): undefined reference to `_restgpr_30_x' > boot1.o: In function `putchar': > boot1.c:(.text+0xe90): undefined reference to `_restgpr_30_x' > boot1.o: In function `main': > boot1.c:(.text.startup+0x528): undefined reference to `_restgpr_18_x' > collect2: error: ld returned 1 exit status > *** [boot1.elf] Error code 1 Before the -Wl, notation changes I did not get this far so -WL,-m = -Wl,elf32ppc_fbsd did help. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Apr-9, at 08:46 PM, Mark Millard wrote: I had written: > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. So I=E2=80=99ve restarted the powerpc64 FreeBSD hosted tests, now based = on the notation -Wl,-m -Wl,elf32ppc_fbsd which sys.mk=E2=80=99s _LDFLAGS assignment should handle okay. One test is building 11.0-CURRENT -r281236 via powerpc64-xtoolchain-gcc = and the other is building 10.1-STABLE -r281235 via the system/normal gcc = 4.2.1. As my builds take considerable time if they actually complete, it will = be a while before I can try any other variations, such as trying a gcc = 4.2.1 cross-build for powerpc. Unfortunately for the purpose at hand: I=E2=80=99m not set up to test = any tier 1 FreeBSD environments at this time. So, for example, I can not = report observations for amd64 building elf_i386_fbsd materials. My tests = may be useful but are not sufficient of themselves to justify edits that = anyone worries might damage tier 1 build-ability. The places I found with notation to adjust if in general the updated = notation works are: > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/uboot/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/src/sys/boot/powerpc/Makefile.inc and the tier 1 case using elf_i386_fbsd: > LD_FLAGS+=3D -m elf_i386_fbsd > /usr/src/sys/boot/i386/Makefile.inc =3D=3D=3D Mark Millard markmi at dsl-only.net Just for reference=E2=80=A6 On 2015-Apr-9, at 07:35 PM, Warner Losh wrote: >=20 >> On Apr 9, 2015, at 7:56 PM, Mark Millard wrote: >>=20 >> =46rom share/mk/bsd.README : >>=20 >> LDFLAGS Additional loader flags. Passed to the loader via CC, >> since that's used to link programs as well, so loader >> specific flags need to be prefixed with -Wl, to work. >>=20 >> But the following 3 powerpc (non-64) examples do not use the -Wl, = notation: >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/ofw/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/uboot/Makefile.inc >>=20 >>=20 >>> LDFLAGS+=3D -m elf32ppc_fbsd >>> /usr/src/sys/boot/powerpc/Makefile.inc >>=20 >> In fact I get errors such as (for that last one when using = powerpc64-gcc via powerpc64-xtoolchain-gcc, executed on a powerpc64): >>=20 >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such = file or directory >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>> powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >>>=20 >>> *** [boot1.elf] Error code 1 >>>=20 >>> make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp >>> 1 error >>=20 >> I do not know if the space between -m and elf... creates a problem = for -Wl, use or not. I would guess that >>=20 >> -Wl,-m,elf32pcc_fbsd >>=20 >> is the proper notation for putting the space through to the ld = variant used. But I=E2=80=99m not to the point of testing the behavior = of that yet. >>=20 >>=20 >>=20 >> i386 seems to have a similar example, although I=E2=80=99m not using = such a FreeBSD environment. >>=20 >>> LD_FLAGS+=3D -m elf_i386_fbsd >>> /usr/src/sys/boot/i386/Makefile.inc >>=20 >>=20 >>=20 >> (This note is shorter in part because figured out more context than I = had last time.) >=20 > I think much of this is historical accident where the boot Makefiles = used to call ld directly, then were converted to call gcc, and gcc = allowed the -m notation like this as a historical compatibility. >=20 > Do thinks still work if you use -Wl, notation? >=20 > Warner >=20 I have a powerpc64-xtoolchain-gcc build going now but that will take a = while. I=E2=80=99ll also need to try a normal one from a gcc 4.2.1 = environment and I=E2=80=99ve not started that yet. And I=E2=80=99m only = set up to test powerpc64 and powerpc. The tier 1 consequences (i386 and = amd64) are outside my environment. Also I sent out another note after discovering a potential problem... > I now see one place where "-Wl,-m,elf32ppc_fbsd" type of notation in = LDFLAGS would not be handled if it ended up involved: >=20 > share/mk/sys.mk:_LDFLAGS =3D ${LDFLAGS:S/-Wl,//g} # = strip -Wl, for LD >=20 > This notation does not deal with turning the extra comma back into a = space. =3D=3D=3D Mark Millard markmi at dsl-only.net