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 7BE5813838B for ; Sun, 21 Sep 2014 22:53:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BA0C3E0955; Sun, 21 Sep 2014 22:53:47 +0000 (UTC) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [96.114.154.171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 51A1AE0955 for ; Sun, 21 Sep 2014 22:53:47 +0000 (UTC) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-12v.sys.comcast.net with comcast id tysy1o0055FMDhs01ytmbM; Sun, 21 Sep 2014 22:53:46 +0000 Received: from [192.168.1.13] ([69.251.152.165]) by resomta-po-19v.sys.comcast.net with comcast id tytk1o00g3aNLgd01ytlBe; Sun, 21 Sep 2014 22:53:46 +0000 Message-ID: <541F56E0.5090501@gentoo.org> Date: Sun, 21 Sep 2014 18:53:20 -0400 From: Joshua Kinard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 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> In-Reply-To: <541F4951.4000409@gentoo.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411340026; bh=CFgurj4hmT+32k+tZLRWPeeacQifcytAGR7QcXgeBMM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aVVE6jj8aRtHri2DQjHzEqL6ezVzE1bPMG6M2K/HNXCiMvxd3tC6Eh8NJQ/LJ/U5M jq6sAGBHq9H9g+NdLLHmO4qllfoShLhHD84+w6+abAkf3CQENxuipH3aVBEBSt58t/ ria8YRP88aaBHfZs1aThvdoQuWW0HBNsx0uo8SlGXxkszac5c6vsJvhtoym73ICEBX 9uh+8l8K1Bv6c2AraYhZ2MUjjslYPeKkiLHNNyhKpxvoa+Pr6MZT8urHEZSQxqx+ko u+BY70Ok0C+/GguCHPwQrkqYKKBGGA0m+Hz6+COfRBKbRUB1cg0bXlVxkeCI4+DKKj moQs2ka8YVzcQ== X-Archives-Salt: 802fc321-599e-4d59-97a2-b23bcd40de6f X-Archives-Hash: 8f4fc222def902463f23ab80a6f08d05 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// 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/ | | | > 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@gentoo.org 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