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

["Anthony G. Basile" <blueness@gentoo.org>]

On 09/17/14 16:19, Anthony G. Basile wrote:
> On 09/17/14 16:13, Markos Chandras wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 09/17/2014 08:52 PM, Anthony G. Basile wrote:
>>> On 09/17/14 15:41, Markos Chandras wrote: On 09/17/2014 08:13 PM,
>>> Anthony G. Basile wrote:
>>>>>> On 09/17/14 13:50, Markos Chandras wrote: On 09/17/2014 02:38
>>>>>> PM, Ian Stakenvicius wrote:
>>>>>>>>> On 17/09/14 04:31 AM, Michał Górny wrote:
>>>>>>>>>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras
>>>>>>>>>> <hwoarang@gentoo.org> napisał(a):
>>>>>>>>>>> Here is some weirdness with eg mips64/n32 multilib
>>>>>>>>>>> profile when trying a world update
>>>>>>>>>>>
>>>>>>>>>>> [ebuild     U  ] sys-devel/libtool-2.4.2-r1:2
>>>>>>>>>>> [2.4.2:2] USE="-static-libs {-test} -vanilla"
>>>>>>>>>>> ABI_MIPS="(n32%*) o32%* -n64%" 0 kB
>>>>>>>>>>>
>>>>>>>>>>> As you can see n32 and o32 are enabled but n64 is
>>>>>>>>>>> not. Obviously this is not full mips64 multilib.
>>>>>>>>>>> This is probably due the portage profile
>>>>>>>>>>> stacking/inheritance problems on mips64, where the
>>>>>>>>>>> mips64/multilib profiles inherit the default o32
>>>>>>>>>>> one. Michal (multilib CC'd) can provide more
>>>>>>>>>>> information on what exactly goes wrong since he
>>>>>>>>>>> understands the problem better than me. Michal
>>>>>>>>>>> also said that on amd64, the multilib profiles
>>>>>>>>>>> defaults to 64-bit only. I believe this contradicts
>>>>>>>>>>> with what someone expects from MIPS64 where all
>>>>>>>>>>> three ABIs need to be present *by default* unless
>>>>>>>>>>> you override the ABI_MIPS variable in make.conf.
>>>>>>>>>>> Correct?
>>>>>>>>>> Well, long story short we inherit from 'top-level'
>>>>>>>>>> profile that has some o32 settings inside. I believe
>>>>>>>>>> that it could be saner to move those from
>>>>>>>>>> arch/mips/mips64 -> arch/mips/mips64/o32 (like we
>>>>>>>>>> have /n32 and /n64 there), so that instead of having
>>>>>>>>>> to unset them, we'd just have them set for the
>>>>>>>>>> relevant real profiles. However, I'm not sure if this
>>>>>>>>>> doesn't come with some pitfalls.
>>>>>>>>> Blueness and I talked about this (proper n32 / n64 /
>>>>>>>>> o32 defaults and forces/masks) in #gentoo-dev two or
>>>>>>>>> three weeks ago; I thought we worked out the correct
>>>>>>>>> modifications to profiles to get it right and he had
>>>>>>>>> already pushed the fixes...  ??
>>>>>> I can't see anything. Did you actually push them? What was
>>>>>> decided as the plan for action?
>>>>>>
>>>>>>> I did not have time to get to them.  I was going to play
>>>>>>> with two different approaches.  One is simply turning off
>>>>>>> o32 at multilib/../n32 level, the other was to restructure
>>>>>>> the profiles entirely and put o32, n32 and 64 on par, not
>>>>>>> inherit from a hire level "default" profile.  I'm leaning
>>>>>>> towards that approach, but I'm worried it might play havoc
>>>>>>> on our users.
>>> Well i need to see the structure for your second approach to
>>> understand what you have in mind. Perhaps the first option is the
>>> safest and ensure some backwards compatibility with existing
>>> mips32 users?
>>>
>>>> Yes it would be more backwards compat, but it is not semetrical.
>>>> The regular (ie glibc) profiles would become:
>>>> [1]   default/linux/mips/13.0/o32 <-change [2]
>>>> default/linux/mips/13.0/n32 [3] default/linux/mips/13.0/n64 [4]
>>>> default/linux/mips/13.0/multilib/o32 <-change [5]
>>>> default/linux/mips/13.0/multilib/n32 [6]
>>>> default/linux/mips/13.0/multilib/n64 [7]
>>>> default/linux/mips/13.0/mipsel/o32               <- change [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     <-change [11]
>>>> default/linux/mips/13.0/mipsel/multilib/n32 [12]
>>>> default/linux/mips/13.0/mipsel/multilib/n64
>> I think that if you symlink the following
>>
>> default/linux/mips/13.0/eapi -> default/linux/mips/13.0/o32/eapi
>> default/linux/mips/13.0/parent -> default/linux/mips/13.0/o32/parent
>>
>> existing default/linux/mips/13.0/ users will be unaffected. But I am
>> not sure if we are allowed to use symlinks (same thing for mipsel)
>>
>> If we can't avoid it then we can send the usual email to the lists
>> informing users for the change. I believe it's not hard for them to
>> figure out what changed and how to select the proper profile for their
>> mips32 boxes.
>
> Let me test first the new profiles.  I will put them on the 
> hardened-dev::profile overlay.  I know they're not hardened, but we do 
> testing of big changes to profiles there.  Then you can review what 
> I've done.
>
> I'm not sure about the sym links either.
>

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.

I'm not sure we want to make such a deep change.  The profiles we would 
present to the user would look like:

   [1]   default/linux/mips/13.0/mips/o32
           default/linux/mips/13.0/mips64/o32   <- distinguish the 
mips/o32 and mips64/o32
   [2]   default/linux/mips/13.0/mips64/n32
   [3]   default/linux/mips/13.0/mips64/n64
   [4]   default/linux/mips/13.0/multilib/o32  <- multilib is 
necessarily mips64
   [5]   default/linux/mips/13.0/multilib/n32  <- multilib is 
necessarily mips64
   [6]   default/linux/mips/13.0/multilib/n64  <- multilib is 
necessarily mips64
   [7]   default/linux/mips/13.0/mipsel/o32
           default/linux/mips/13.0/mips64el/o32      <- distinguish the 
mipsel/o32 and mips64el/o32
   [8]   default/linux/mips/13.0/mips64el/n32
   [9]   default/linux/mips/13.0/mips64el/n64
   [10]  default/linux/mips/13.0/mipsel/multilib/o32    <- multilib is 
necessarily mips64el
   [11]  default/linux/mips/13.0/mipsel/multilib/n32    <- multilib is 
necessarily mips64el
   [12]  default/linux/mips/13.0/mipsel/multilib/n64    <- multilib is 
necessarily mips64el

No need to touch the rest.
   [13]  hardened/linux/musl/mips
   [14]  hardened/linux/musl/mips/mipsel
   [15]  default/linux/uclibc/mips
   [16]  hardened/linux/uclibc/mips
   [17]  default/linux/uclibc/mips/mipsel
   [18]  hardened/linux/uclibc/mips/mipsel


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.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA