Date: Tue, 20 Mar 2012 11:35:42 -0600 From: Warner Losh <imp@bsdimp.com> To: "Jayachandran C." <c.jayachandran@gmail.com> Cc: Juli Mallett <juli@clockworksquid.com>, "freebsd-mips@FreeBSD.org" <freebsd-mips@FreeBSD.org> Subject: Re: Unbreaking ports with n64 MIPS. Message-ID: <DEFF7F2C-0D27-4C00-BF4C-557C8C13CBBF@bsdimp.com> In-Reply-To: <CA%2B7sy7AROF0tmSse7Dx3%2BhmPNQ57MtGvqJe6ndqaYSMz240nFw@mail.gmail.com> References: <CACVs6=8z4BYcpQ=jVKLLb7v2LmSD-MRxXQdYRrOj-hG1j572Cg@mail.gmail.com> <E580AB5B-AD2A-4E04-A040-8E9E5D667040@bsdimp.com> <CACVs6=_FXqM2vjx1B4C819kuapaCXek-RfVwo0YPsk74r4%2BgkA@mail.gmail.com> <CA%2B7sy7AROF0tmSse7Dx3%2BhmPNQ57MtGvqJe6ndqaYSMz240nFw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 2012, at 8:54 AM, Jayachandran C. wrote: > On Sat, Mar 17, 2012 at 9:14 AM, Juli Mallett <juli@clockworksquid.com> wrote: >> 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. 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. > > 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. 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. >> >> 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. > > 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DEFF7F2C-0D27-4C00-BF4C-557C8C13CBBF>