From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5FB3713838B for ; Mon, 22 Sep 2014 01:11:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94232E0894; Mon, 22 Sep 2014 01:11:01 +0000 (UTC) Received: from virtual.dyc.edu (mail.virtual.dyc.edu [67.222.116.22]) by pigeon.gentoo.org (Postfix) with ESMTP id 3F626E0894 for ; Mon, 22 Sep 2014 01:11:01 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) by virtual.dyc.edu (Postfix) with ESMTPSA id 8D83E7E025D for ; Sun, 21 Sep 2014 21:11:00 -0400 (EDT) Message-ID: <541F7726.5070305@opensource.dyc.edu> Date: Sun, 21 Sep 2014 21:11:02 -0400 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 To: gentoo-mips@lists.gentoo.org Subject: Re: [gentoo-mips] multilib problems on mips64 profiles References: <541412C5.4090809@gentoo.org> <20140917103121.6e822b45@pomiot.lan> <54198ECB.7010803@gentoo.org> <5419C9FD.6060106@gentoo.org> <5419DD6F.4000801@opensource.dyc.edu> <5419E3FF.9050408@gentoo.org> <5419E690.5010905@gentoo.org> <5419EB70.10209@gentoo.org> <5419ECD0.7000903@gentoo.org> <541F4951.4000409@gentoo.org> <541F56E0.5090501@gentoo.org> In-Reply-To: <541F56E0.5090501@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: fb1e0d6e-0109-4084-a83d-feb92833ddb0 X-Archives-Hash: 536c731a48439668973512f2e449bd83 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// 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 > , 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