Unbreaking ports with n64 MIPS.

[Jayachandran C.]

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

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.