Unbreaking ports with n64 MIPS.

[Warner Losh]

On Mar 16, 2012, at 9:44 PM, Juli Mallett 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.

I went with mipseb and mips64eb for two reasons.  The former because NetBSD did it this way, and the latter for symmetry (NetBSD used mips64 but allowed mips64eb as an alias).  The n32eb ABI stuff I didn't do, and agree with you: they aren't the architecture, since n32 binaries can easily co-exist with n64.

>  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 argument for adding the alaises is transition from older release.

> 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.

This is a bigger discussion.  Several issues:

(1) Multilib.  If we had multilib, then we can build one or more of {o32, n32, n64}.  Then the ABI decision would be what to build for the entire system.  SGI used n64 for everything.  Other systems have a default ABI that we build.
(2) What's the default ABI that tools produce?  Is this tied to MACHINE_ARCH?  We spent a lot of time making sure that we have the right default tools so we build everything correctly.
(3) Do we support building other ABIs as part of the build system.  We had that before, but TARGET_BIG_ENDIAN removal killed that.  There's pros and cons of adding support here.  Multiple ABIs does junk up a lot of places in very machine specific ways.  Lots of places need tweaking if we go back to this.

MACHINE_ABI is what we need.  But do we really need it?  If we want to support building different ABIs for the same MACHINE_ARCH, then we'll need some way to persist this so we can be self-hosting.  Right now the 'make this the default ABI' method for gcc/binutils persists this information and makes things work nicely.  sysctl likely is the way to go here.

mips*n32* has always been a hack of convenience.  I'm pretty sure we're the only ones that do it.

> 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'm sure that this has decayed into dust.  I tried to get gcc to generate -msoft-float on x86, and it just didn't work.  Today, I think we burn this into the default settings of the toolchain we use to bootstrap the system.  We can have a knob for it, but it is purely a userland concept: there's no floating point in the kernel to speak of.  MACHINE_FLOAT={hard,soft} might not be a bad idea, with the value exported via sysctl.  Not sure if make needs to grow support for this and MACHINE_ABI, or if it would suffice for the necessary Makefiles and/or .mk files to query the sysctl value.

> 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?

Doesn't cache aliasing occur when you have multiple TLBs pointing to the same physical page, which is a MIPSy no-no?

I haven't thought about this in ages.  I believe that it is complex to design, but relatively simple to implement.  I did some preliminary looking into this a couple of years ago, but never made it out of the early explorer stage for want of time.

Warner

> Thanks,
> Juli.
> 
> 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"
>>> 
>>> 
>> 
> 
>