From owner-freebsd-mips@FreeBSD.ORG Tue Mar 20 17:37:02 2012 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9227106566B for ; Tue, 20 Mar 2012 17:37:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7329C8FC0A for ; Tue, 20 Mar 2012 17:37:02 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q2KHZlEQ018660 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2012 11:35:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 20 Mar 2012 11:35:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Jayachandran C." X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 20 Mar 2012 11:35:51 -0600 (MDT) Cc: Juli Mallett , "freebsd-mips@FreeBSD.org" Subject: Re: Unbreaking ports with n64 MIPS. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:37:02 -0000 On Mar 20, 2012, at 8:54 AM, Jayachandran C. wrote: > On Sat, Mar 17, 2012 at 9:14 AM, Juli Mallett = wrote: >> Hey Warner & others, >>=20 >> Here's the patch I intend to commit in the near future, and then I'll >> add an UPDATING entry and send out an E-Mail blast to the list: >>=20 >> http://people.freebsd.org/~jmallett/noeb.diff >>=20 >> I've decided not to make mips64eb (and mipseb and mipsn32eb) aliases, >> but I'm willing to be convinced to do so. It's a simple matter then >> to have a single regex in the few things that report the TARGET_ARCH >> or MACHINE_ARCH (e.g. GCC) that converts those aliases to the >> canonical values, and to otherwise just expand the regexes in this >> patch a little bit. We wouldn't report things with eb in them >> anywhere, and self-hosted builds would work, but it seems like we = have >> a small enough community of MIPS users that this actually won't be a >> big deal. I'm willing to do the work on aliases, but only if there's >> strong requests. >=20 > The changes look fine. I can do native build of mips64 kernel, world > and ports on XLP, so let me know if need any help testing this. >=20 >> Two other things have come up on this thread: >>=20 >> 1) n32 is an ABI not a sensible TARGET_ARCH. We need TARGET_ABI. We >> need GCC to report something like mips64-freebsdelf or freebsdelfn32 >> or freebsdn32 or whichever. We need things to be able to detect = that. >> Anyone who cares about n32 should really work on making it easy to >> use n32 worlds on n64 kernels. I'm happy to help with this as I have >> a pretty good idea where the pitfalls are, but it's non-trivial work, >> and involves putting conditionals all through the 32-bit compat code. >> For worlds, n32 should not be a TARGET_ARCH. Kernels should not be >> n32. And so on. >>=20 >> 2) Soft- vs. hard-float. How should a user select? We used to have >> some way, I know, for x86 systems which needed soft float, so they >> didn't use the slower fp emulation in the kernel. >=20 > I think TARGET_CPUTYPE and TARGET_ARCH can be extended a bit to take > care of the most of these. Here's is my suggestion on how the > variables can work. >=20 > TARGET_CPUTYPE: Controls CPU specific optimization like soft-float > vs. hard-float and r1 vs r2 vs. extended instruction sets. mips32, > mips64 mips32r2, mips64r2, xlp(64r2+hardfloat), > octeon(64r2+softfloat) would be possible values for this. >=20 > The effect of these on different build targets would be - > kernel: builds kernel optimized for the CPU. > world: build a world optimized for the target CPU, the resulting > world will not work on other/lesser CPU types. > toolchain - not affected by this. >=20 > TARGET_ARCH: Controls ABI and endianness. Values are mips, mipsel, > mips64, mips64el, mipsn32, mipsn32el. Once we become tier 2, iinstall > binaries and ports should be available for each of these. >=20 > mips64: (default cpu - mips64r1 soft-float) > kernel: n64 (o32 binary support COMPAT_FREEBSD32 etc.) > userspace: n64 userspace and libraries, o32/n32? multilib support can = be added > toolchain: generates binaries for default cpu type >=20 > mipn32 : (default cpu - mips64r1 soft-float) > kernel: n32 (with o32 elf binary support?) > user-space: n32 userspace, o32? multilib support > toolchain: default to n32 binaries >=20 > mips (default cpu type: mips32 r1, soft-float) > kernel - o32 elf binary support > userspace - o32 why not also support n32 binaries (apart from the need for someone to do = the work :)? > The only thing I see as an issue here is that if someone builds world > with a specialized CPUTYPE, they will not be able to use standard > ports binaries. This would mean that we would need to extend multi-lib > with CPU types. Frist of all, why is that? Second of all, how would the extentions to multilib look and how would = that enable people to run standard ports-built packages created by the = project? I generally like this partitioning, but haven't been working with this = stuff enough day to day to know if all the details are correct. Warner=