From owner-freebsd-mips@FreeBSD.ORG Tue Mar 20 14:54:14 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 C87CE1065670 for ; Tue, 20 Mar 2012 14:54:14 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 557338FC17 for ; Tue, 20 Mar 2012 14:54:14 +0000 (UTC) Received: by wern13 with SMTP id n13so154009wer.13 for ; Tue, 20 Mar 2012 07:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kGojxA7jpXZ1r0KLT8B10eEOf8zfvB2BF6fF2qXj3xc=; b=fLNiCP8XpgMwCigsrYcSB3i/V5+l648rzbl4KjMrkcaIM5bNlThcRZB9L6FyiW0fvc VEAXd4J7fiXRJMhUurthllgo0Jk0veZ6F2m49mcaujHRm64BS98XMZiMv6RXsB+0Yg8f kWUUDRvZphfqlrRarE8VzKdOKKyr7P2z0eRfScTR/WWjRYK8spqtDSir+KYDeBxU/3gu mTSuWD98Gzsxb3f4QvRa04ANpL4tC9WroePvJDbDdiZNa3yG8tAfQY9H6M+hzWAt2Mkj eyMDarLkefqRFSYPwRsR1ZT7ZbvFMKn/fH4cHWyX+h5iUSZXBvWqOl3SXgae9YTVFaL0 ZUxw== MIME-Version: 1.0 Received: by 10.180.24.4 with SMTP id q4mr29517388wif.7.1332255253543; Tue, 20 Mar 2012 07:54:13 -0700 (PDT) Received: by 10.216.62.81 with HTTP; Tue, 20 Mar 2012 07:54:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Mar 2012 20:24:13 +0530 Message-ID: From: "Jayachandran C." To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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 14:54:14 -0000 On Sat, Mar 17, 2012 at 9:14 AM, Juli Mallett wro= te: > Hey Warner & others, > > 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: > > http://people.freebsd.org/~jmallett/noeb.diff > > I've decided not to make mips64eb (and mipseb and mipsn32eb) aliases, > but I'm willing to be convinced to do so. =A0It'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. =A0We 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. =A0I'm willing to do the work on aliases, but only if there's > strong requests. 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. > Two other things have come up on this thread: > > 1) n32 is an ABI not a sensible TARGET_ARCH. =A0We need TARGET_ABI. =A0We > need GCC to report something like mips64-freebsdelf or freebsdelfn32 > or freebsdn32 or whichever. =A0We need things to be able to detect that. > =A0Anyone who cares about n32 should really work on making it easy to > use n32 worlds on n64 kernels. =A0I'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. =A0Kernels should not be > n32. =A0And so on. > > 2) Soft- vs. hard-float. =A0How should a user select? =A0We 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. 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. 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. 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. 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. 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 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 mips (default cpu type: mips32 r1, soft-float) kernel - o32 elf binary support userspace - o32 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. JC.