1 |
On 07/09/14 05:09, Joshua Kinard wrote: |
2 |
> On 07/08/2014 21:48, Matthew Thode wrote: |
3 |
>> arm has a historical problem with stabilization, while keywording |
4 |
>> doesn't require access to all arm sub-arches the problem with the |
5 |
>> stabilization slowness causes running a full ~arm to become hard. By |
6 |
>> that I mean that if someone keywords something for arm because it works |
7 |
>> on armv7 and I run ~arm because stabilization takes forever then my |
8 |
>> system may break because of both non-stabilized packages and because I |
9 |
>> could be running armv6. |
10 |
>> |
11 |
>> In any case I propose splitting out arm into armv4, armv5, armv6 and |
12 |
>> armv7. armv8 seems to be here already as arm64. |
13 |
> Couldn't this be better handled with some profile work? These sound like |
14 |
> versions of Instruction Set Architectures. In the MIPS world, you have your |
15 |
> original ISAs, mips1 through mips4, then you have the newer variants of |
16 |
> mips32r* (branches from mips2) and mips64r* (branches from mips4). Anything |
17 |
> supporting mips4 could also support earlier ISAs. Throw in our three |
18 |
> supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI, |
19 |
> Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can cover |
20 |
> all of this with just a single 'mips' keyword in the tree. |
21 |
|
22 |
Yes, this should be done via the profiles. Code requiring later ISAs |
23 |
and/or with extensions like thumb and neon will probably break on lower |
24 |
ISAs. These should be masked on the profiles. |
25 |
|
26 |
> Is that similar to how these ARM variants work? Can an armv7 run code for |
27 |
> armv6 and earlier? |
28 |
|
29 |
Its a bit more complicated that MIPS. You can test for yourself. I did |
30 |
this via a chromebook (cortex-a15) using my hardened stages |
31 |
(march=armv7a) available at <mirror>/experimental/arm/hardened, so you |
32 |
can test too: |
33 |
|
34 |
chrome ~ # echo "int main() { return 0; }" > test.c |
35 |
chrome ~ # gcc -march=armv7-a -o test test.c |
36 |
chrome ~ # gcc -march=armv6 -o test test.c |
37 |
chrome ~ # gcc -march=armv5 -o test test.c |
38 |
chrome ~ # gcc -march=armv4 -o test test.c |
39 |
chrome ~ # gcc -march=armv3 -o test test.c |
40 |
/tmp/ccZjsI2O.s: Assembler messages: |
41 |
/tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode |
42 |
`bx lr' |
43 |
chrome ~ # gcc -march=armv3m -o test test.c |
44 |
/tmp/cc1o59kQ.s: Assembler messages: |
45 |
/tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode |
46 |
`bx lr' |
47 |
chrome ~ # gcc -march=armv2 -o test test.c |
48 |
/tmp/ccmTNSyh.s: Assembler messages: |
49 |
/tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode |
50 |
`bx lr' |
51 |
chrome ~ # gcc -march=armv2a -o test test.c |
52 |
/tmp/ccTIXZ46.s: Assembler messages: |
53 |
/tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode |
54 |
`bx lr' |
55 |
chrome ~ # gcc --version |
56 |
gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3 |
57 |
Copyright (C) 2012 Free Software Foundation, Inc. |
58 |
This is free software; see the source for copying conditions. There is NO |
59 |
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
60 |
|
61 |
|
62 |
So it looks like gcc can emit compat code back to armv4. This doesn't |
63 |
necessarily mean that armv2 code won't run on an armv7a, but that |
64 |
gcc-4.7.3-r1 can't produce such code, which is sufficient for our |
65 |
purposes of masking. |
66 |
|
67 |
|
68 |
> |
69 |
> Splitting 'arm' into four new keywords, on top of 'arm64' is just going to |
70 |
> give you guys major headaches later. You might even consider dedicated USE |
71 |
> flags for the arm subvariants and use those to control things in an ebuild |
72 |
> where applicable. |
73 |
|
74 |
arm64 might as well be a totally different arch. There is no |
75 |
compatibility between 32-bit and 64-bit arm variants --- at least not |
76 |
that I know of, its a new arch that I'm just now getting familiar with. |
77 |
On the other hand ppc and ppc64 should never have been split, but that's |
78 |
another story. |
79 |
|
80 |
We do not want keywords for every subarch otherwise we'll go crazy |
81 |
stabilizing. We could adopt a policy of stabilizing on armv7a and when |
82 |
a package doesn't build on a lower ISA, just mask it in the profiles. |
83 |
|
84 |
> |
85 |
>> I think this would be beneficial because of not all developers that want |
86 |
>> to help with arm have or what all the sub-arches necessary. It also |
87 |
>> allows us to move faster on stabilization because most of us have access |
88 |
>> to armv7 a bit easier. This would take some pressure off of the people |
89 |
>> doing stabilization for older sub-arches, but not much. |
90 |
> What's the support status of Gentoo on the older variants, such as armv4 and |
91 |
> armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3 |
92 |
> cache? Lots of memory? Generally, anything that could be a bottleneck or |
93 |
> severely increase the build time should be weighed against the potential |
94 |
> number of users and possibly support dropped if there aren't enough |
95 |
> developers or contributing users to maintain it. |
96 |
> |
97 |
> I.e., w/ MIPS, we don't support anything under the mips3 ISA, which includes |
98 |
> DECStations (Debian does support those). Build times would just be |
99 |
> tremendously slow and I haven't seen a lot of desire to support those. |
100 |
> |
101 |
|
102 |
Regarding MIPS, this isn't totally true. I'm willing to support mips-I |
103 |
for embedded systems, although right now I'm just doing mipsel3 and |
104 |
mip32r2. I used to have mips-I big endian uclibc stages. Also, you |
105 |
don't have to hit slow build times because you can build mips-I on any |
106 |
mips system of the same endianness. |
107 |
|
108 |
|
109 |
-- |
110 |
Anthony G. Basile, Ph.D. |
111 |
Gentoo Linux Developer [Hardened] |
112 |
E-Mail : blueness@g.o |
113 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
114 |
GnuPG ID : F52D4BBA |