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

[Anthony G. Basile]

On 09/21/14 18:53, Joshua Kinard wrote:
> 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).

I agree that there shouldn't be any userland difference, but I'm not 
100% sure.  Anyhow, let's go with that assumption for now.

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

Not exactly.  The problem is that everything inherits from 
profiles/arch/mips and currently that forces o32 with mgorny's multilib 
stuff.  We need to get that out of the way for the other profiles that 
inherit it.

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

That's one approach, but I'm trying to find the least intrusive. I do 
have the problem fixed with the following:

   [1]   default/linux/mips/13.0/o32
   [2]   default/linux/mips/13.0/n32
   [3]   default/linux/mips/13.0/n64
   [4]   default/linux/mips/13.0/multilib/o32
   [5]   default/linux/mips/13.0/multilib/n32
   [6]   default/linux/mips/13.0/multilib/n64
   [7]   default/linux/mips/13.0/mipsel/o32
   [8]   default/linux/mips/13.0/mipsel/n32
   [9]   default/linux/mips/13.0/mipsel/n64
   [10]  default/linux/mips/13.0/mipsel/multilib/o32
   [11]  default/linux/mips/13.0/mipsel/multilib/n32
   [12]  default/linux/mips/13.0/mipsel/multilib/n64

and would like to push this through as a fix for now.  1 and 4 have 
CHOST=mips-unknown-linux-gnu and mipsel-unknown-linux-gnu respectively. 
  2,3 and 8,9 have mips64-unknown-linux-gnu and 
mips64el-unknown-linux-gnu respectively.  Only users of profiles 1 and 7 
need to change their sym link one level down to ../o32.  That was 
necessary to move the o32 stuff out of the way of profiles/arch/mips.

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

I like this, but the problem is disentangling the situation under 
arch/mips, not under default/linux/mips.  Again, the inheritance problem 
stems from everything under profiles/arch/mips inheriting from 
profiles/arch/mips.  So even if you do implement the above, you still 
have to address the issue of how the arch/mips stuff is stacking.

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

I'm leaning back towards the above approach and not Ian's.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]