Unbreaking ports with n64 MIPS.
Warner Losh
imp at bsdimp.com
Tue Mar 20 17:37:02 UTC 2012
On Mar 20, 2012, at 8:54 AM, Jayachandran C. wrote:
> On Sat, Mar 17, 2012 at 9:14 AM, Juli Mallett <juli at 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
More information about the freebsd-mips
mailing list