Re: [gentoo-mips] multilib problems on mips64 profiles

[Joshua Kinard]

On 09/21/2014 17:55, Anthony G. Basile wrote:
> On 09/17/14 16:19, Anthony G. Basile wrote:
[snip]
>
> This isn't going to work.  The problem is that the above structure doesn't
> distinguish between mips/o32 and mips64/o32 (and equivalent el versions).  Now
> mips64/o32 is funny, but possible: it would be o32 (a 32-bit abi) on 64 bit
> arch/kernel, like ppc64-32ul.  The structure is possible at the level of
> profile/arch, but it would mean a deep restructuring of default/linux/mips/13.0.

Err, I've been using this setup for the last 9+ years?  My Octane and O2 both
boot mips64 kernels and run an o32-only userland.  It works fine with the
current profile setup.  You just use a mips-unknown-linux-gnu CHOST.  I may not
be able to fully utilize all of the CPU registers like I would under n32, but
that's never been an issue for me.

So there should be no need to differentiate at the userland level between
mips/o32 and mips64/o32.  As long as the CHOST is set correctly, o32 will work
fine under a mips64 kernel (caveat: make sure CONFIG_MIPS32_O32 is set in the
kernel).

Correct me if wrong, but it seems the core problem here is that multilib
inherits from the o32 base profile.  While I think the proper longterm fix is
to have more discrete, modular/pluggable profile components (like OOP and
multiple base classes), that's not going to happen in Portage for a long time.

So I think the solution is to split the profiles into "mips" and "mips64",
i.e., 32/ and 64/ under the 'mips' base profile folder.  32/ contains
everything needed to run pure o32-only under either a mips or mips64 kernel.
I.e., mips-unknown-linux-gnu CHOST.  So on my Octane, /etc/portage/make.profile
symlinks to /usr/portage/default/linux/mips/32/<VERSION>/

64/ is where the fun is at.  I think the default ABI there should be n32 at the
base, with a subprofile for multilib that itself contains subprofiles to handle
the combinations of ABIs desired.  Still have to workout what CHOST you use for
the base (GNU standard for n32 is mips64-unknown-linux-gnueabin32).  multilib
would just use mips64-unknown-linux-gnu, and -mabi would be passed to gcc to
pick the ABI to build for.

Also, if we are going to do any kind of reorganizing of the profiles, let's not
do it under 13.0.  Personally, I'd like to get away from datestamps as profile
versions (13.0 refers to 2013) and either pick a fixed version number that we
increment or come up with some other kind of versioning scheme.  Or just do
away with it altogether and have something like a "stable" profile where things
work and an "unstable" branch that only exists when we're doing insane changes
to the profiles, which after testing, becomes "stable" (and current "stable"
becomes "oldstable" or such).

If we have to stick with datestamped versions, then use 15.0.  Cause it'll be
2015 by the time this goes active.

rough draft of the top-level layout.  Doesn't care about chosen libc, ISA, or
<VERSION>, but does reflect endianness.

default/linux/mips
   |
   |-32/
   |  |-be/
   |  |-le/
   |
   |-64/
   |  |-be/
   |  |-le/
   |  |
   |  |-multilib/
   |  |  |-be/
   |  |  |-le/
   |  |
   |


> Maybe we just don't want to support mips64/o32?  I'm starting to lean towards
> Ian's simple but asymmetric solution of turning off o32 in the inheriting
> profiles.

NAK

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic