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
next prev parent 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