Re: [gentoo-dev] splitting out arm keywords

[Manuel Rüger]

On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
> On 07/09/14 05:09, Joshua Kinard wrote:
>> On 07/08/2014 21:48, Matthew Thode wrote:
>>> arm has a historical problem with stabilization, while keywording
>>> doesn't require access to all arm sub-arches the problem with the
>>> stabilization slowness causes running a full ~arm to become hard.  By
>>> that I mean that if someone keywords something for arm because it works
>>> on armv7 and I run ~arm because stabilization takes forever then my
>>> system may break because of both non-stabilized packages and because I
>>> could be running armv6.
>>>
>>> In any case I propose splitting out arm into armv4, armv5, armv6 and
>>> armv7.  armv8 seems to be here already as arm64.
>> Couldn't this be better handled with some profile work?  These sound like
>> versions of Instruction Set Architectures.  In the MIPS world, you
>> have your
>> original ISAs, mips1 through mips4, then you have the newer variants of
>> mips32r* (branches from mips2) and mips64r* (branches from mips4).
>> Anything
>> supporting mips4 could also support earlier ISAs.  Throw in our three
>> supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
>> Cobalt, Yeelong/Loongson, etc), and life can be quite fun.  But we can
>> cover
>> all of this with just a single 'mips' keyword in the tree.
>
> Yes, this should be done via the profiles.  Code requiring later ISAs
> and/or with extensions like thumb and neon will probably break on lower
> ISAs.  These should be masked on the profiles.
>
>> Is that similar to how these ARM variants work?  Can an armv7 run code
>> for
>> armv6 and earlier?
>
> Its a bit more complicated that MIPS.  You can test for yourself.  I did
> this via a chromebook (cortex-a15) using my hardened stages
> (march=armv7a) available at <mirror>/experimental/arm/hardened, so you
> can test too:
>
> chrome ~ # echo "int main() { return 0; }" > test.c
> chrome ~ # gcc  -march=armv7-a -o test test.c
> chrome ~ # gcc  -march=armv6 -o test test.c
> chrome ~ # gcc  -march=armv5 -o test test.c
> chrome ~ # gcc  -march=armv4 -o test test.c
> chrome ~ # gcc  -march=armv3 -o test test.c
> /tmp/ccZjsI2O.s: Assembler messages:
> /tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
> `bx lr'
> chrome ~ # gcc  -march=armv3m -o test test.c
> /tmp/cc1o59kQ.s: Assembler messages:
> /tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
> `bx lr'
> chrome ~ # gcc  -march=armv2 -o test test.c
> /tmp/ccmTNSyh.s: Assembler messages:
> /tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
> `bx lr'
> chrome ~ # gcc  -march=armv2a -o test test.c
> /tmp/ccTIXZ46.s: Assembler messages:
> /tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
> `bx lr'
> chrome ~ # gcc --version
> gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
> Copyright (C) 2012 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> So it looks like gcc can emit compat code back to armv4.  This doesn't
> necessarily mean that armv2 code won't run on an armv7a, but that
> gcc-4.7.3-r1 can't produce such code, which is sufficient for our
> purposes of masking.
>
>
>>
>> Splitting 'arm' into four new keywords, on top of 'arm64' is just
>> going to
>> give you guys major headaches later.  You might even consider
>> dedicated USE
>> flags for the arm subvariants and use those to control things in an
>> ebuild
>> where applicable.
>
> arm64 might as well be a totally different arch.  There is no
> compatibility between 32-bit and 64-bit arm variants --- at least not
> that I know of, its a new arch that I'm just now getting familiar with.
> On the other hand ppc and ppc64 should never have been split, but that's
> another story.
>
> We do not want keywords for every subarch otherwise we'll go crazy
> stabilizing.  We could adopt a policy of stabilizing on armv7a and when
> a package doesn't build on a lower ISA, just mask it in the profiles.
>
>>
>>> I think this would be beneficial because of not all developers that want
>>> to help with arm have or what all the sub-arches necessary.  It also
>>> allows us to move faster on stabilization because most of us have access
>>> to armv7 a bit easier.  This would take some pressure off of the people
>>> doing stabilization for older sub-arches, but not much.
>> What's the support status of Gentoo on the older variants, such as
>> armv4 and
>> armv5 stuff?  How fast is the CPU clock on those?  Do they include L2/L3
>> cache?  Lots of memory?  Generally, anything that could be a
>> bottleneck or
>> severely increase the build time should be weighed against the potential
>> number of users and possibly support dropped if there aren't enough
>> developers or contributing users to maintain it.
>>
>> I.e., w/ MIPS, we don't support anything under the mips3 ISA, which
>> includes
>> DECStations (Debian does support those).  Build times would just be
>> tremendously slow and I haven't seen a lot of desire to support those.
>>
>
> Regarding MIPS, this isn't totally true.  I'm willing to support mips-I
> for embedded systems, although right now I'm just doing mipsel3 and
> mip32r2.  I used to have mips-I big endian uclibc stages.  Also, you
> don't have to hit slow build times because you can build mips-I on any
> mips system of the same endianness.
>
>

I think arm64 is getting keyworded using qemu, because nobody owns any
hardware yet. Can't we use qemu for armv5, too?
You won't need any additional hardware to handle stabilization. Just
test on armv7 hw and in your qemu instance.


Cheers

Manuel