public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Anthony G. Basile" <basile@opensource.dyc.edu>
To: gentoo-mips@lists.gentoo.org
Subject: Re: [gentoo-mips] multilib problems on mips64 profiles
Date: Sun, 21 Sep 2014 21:11:02 -0400	[thread overview]
Message-ID: <541F7726.5070305@opensource.dyc.edu> (raw)
In-Reply-To: <541F56E0.5090501@gentoo.org>

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
(716) 829-8197


  reply	other threads:[~2014-09-22  1:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-13  9:47 [gentoo-mips] multilib problems on mips64 profiles Markos Chandras
2014-09-13 13:54 ` Anthony G. Basile
2014-09-17  8:31 ` Michał Górny
     [not found]   ` <54198ECB.7010803@gentoo.org>
2014-09-17 17:50     ` Markos Chandras
2014-09-17 19:13       ` Anthony G. Basile
2014-09-17 19:41         ` Markos Chandras
2014-09-17 19:52           ` Anthony G. Basile
2014-09-17 20:13             ` Markos Chandras
2014-09-17 20:19               ` Anthony G. Basile
2014-09-21 21:55                 ` Anthony G. Basile
2014-09-21 22:45                   ` Matt Turner
2014-09-21 22:53                     ` Anthony G. Basile
2014-09-21 22:53                   ` Joshua Kinard
2014-09-22  1:11                     ` Anthony G. Basile [this message]
2014-09-22  1:12                       ` Anthony G. Basile
2014-09-22  1:29                         ` Joshua Kinard
2014-09-22 10:39                           ` Anthony G. Basile
2014-09-22  1:49                       ` Joshua Kinard
2014-09-22 10:53                         ` Anthony G. Basile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=541F7726.5070305@opensource.dyc.edu \
    --to=basile@opensource.dyc.edu \
    --cc=gentoo-mips@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox