Unbreaking ports with n64 MIPS.

Juli Mallett juli at clockworksquid.com
Sat Mar 17 03:44:50 UTC 2012

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:


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.

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.

Another conversation I want to have is about pmap, and since I don't
want to write out enough to start a whole thread about it, and I hope
everyone's reading this, and I've already covered some far afield
stuff, here:

We need to be thinking about superpages.  This is non-trivial even
though MIPS is just about ideal for superpages.  For one thing, it'd
be really nice if we did not split TLB entries as we currently do, so
the default PAGE_SIZE would be 8K, and then we wouldn't have to deal
with TLB behavior where superpages are involved.  Does the TLB always
use the nearest match?  How does it impact performance to have two TLB
entries covering the same range of addresses?  It depends on how the
hardware implements TLB lookups, yes?  Wouldn't it be nice to not have
to split the TLB?  Wouldn't it?  I know I bring this up a lot, but it
seems like it really would make superpages just slightly less ugly.  I
mean, you do tlbp and you find that your VA is covered by the TLB, but
the entry it's in is split, and your VA isn't covered by a superpage,
but the one in the TLB is, so you have to add a more specific entry,
and suddenly all of your functions using the TLB have gotten
non-trivially complex.

Have I missed a trick?


On Thu, Mar 15, 2012 at 09:17, Warner Losh <imp at bsdimp.com> wrote:
> Hi Juli,
> I'd be fine with mips64 and mips64eb being the same, and moving from the former to the latter as the uname reported value. I almost did it when I was doing the stuff, but the pedants were against me and I didn't have any good amo to push back at them.  This would be a good reason.  The code was a little simpler when I always specified the eb on the end for all mips ports, so there's some tricks in the tree to keep expressions from getting too gross you'll have to watch out for.
> As for IRIX, n32 binaries were run on it, but there never was a n32 kernel that I recall.  It was just a funky ABI that you could compile your programs to if they had problems with the n64 ABI.  So the OS didn't report anything special there.  Our notion of an n32 kernel is historically a bit funkadelic.
> Warner
> On Mar 15, 2012, at 1:46 AM, Juli Mallett wrote:
>> All,
>> Does anyone object to changing the target name of mips64eb to be
>> rendered as mips64?  It's difficult to build ports because although
>> the redundant "mipseb" as widely-recognized as synonymous as "mips",
>> our quirky use of "mips64eb" instead of "mips64" just plain breaks
>> stuff.  "mips64el" is, of course, recognized, but it's generally
>> assumed that MIPS is big-endian by default.  I understand this
>> assumption wasn't made in FreeBSD because the port that was committed
>> focused early on a number of little-endian MIPS systems, but it seems
>> worthwhile to switch.  I'm happy to make the relevant changes.
>> Thanks,
>> Juli.
>> PS: This may only need to be changed in how we name things in our GCC
>> and binutils to fix ports, but I'd rather change everything else to
>> match for the sake of consistency.
>> PPS: What to do for n32?  I think mips64{,el} is right for GCC and
>> binutils, with something like "n32" in the OS name, but I haven't
>> booted IRIX in almost a decade, so I can't remember what the
>> convention is.  I don't even know if there's software in ports that
>> would care.
>> _______________________________________________
>> freebsd-mips at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
>> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"

More information about the freebsd-mips mailing list