[OE-core] [PATCH 3/3] glib.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Andre McCurdy]

On Thu, Mar 3, 2016 at 6:00 AM, Phil Blundell <pb at pbcl.net> wrote:
> On Thu, 2016-03-03 at 14:18 +0100, Martin Jansa wrote:
>> On Thu, Mar 03, 2016 at 01:02:35PM +0000, Phil Blundell wrote:
>> > On Wed, 2016-01-27 at 15:28 -0800, Andre McCurdy wrote:
>> > > -ARM_INSTRUCTION_SET = "arm"
>> > > +ARM_INSTRUCTION_SET_armv4 = "arm"
>> > > +ARM_INSTRUCTION_SET_armv5 = "arm"
>> >
>> > Although I agree that this is a net improvement over the old code
>> > in
>> > almost all cases, this patch is not quite right.  The reason for
>> > the
>> > original override is that there is assembler code in glib which
>> > won't
>> > compile as Thumb-1 (but is ok in Thumb-2).  Thumb-2 is only
>> > available
>> > in ARMv6T2 and newer architectures so with your patch it looks like
>> > compilation on arm1136jf-s (which is ARMv6 not ARMv6T2) would now
>> > fail.
>>
>> If the MACHINE doesn't have thumb in TUNE_FEATURES (for selected
>> DEFAULTTUNE) won't use -mthumb, so building on ARMv6 shouldn't fail
>> or I didn't get your point.
>
> Well, right, clearly it won't fail if you don't select thumb at all,
> but the same is true of armv4 and armv5 so by that line of argument the
> overrides here are completely redundant.  If you enable thumb on ARMv6
> then glib-2.0 fails to build in the same way as it would have done for
> armv4/armv5 without the overrides on ARM_INSTRUCTION_SET.
>
> (Admittedly though, if you actually try to enable thumb with ARMv6 then
> there are other problems that you need to fix before you can get as far
> as even trying to compile glib-2.0.  This is perhaps further evidence
> that nobody is doing this in practice!)
>
>>
>> > 3. Take the view that it's now nearly fifteen years since Thumb-2
>> > was
>> > introduced, OE-core no longer needs to pander explicitly to Thumb-
>> > 1,
>> > and we should just remove all this scar tissue entirely.  Distros
>> > that
>> > do want to target Thumb-1 can still maintain the appropriate
>> > compatibility stuff (which is probably only a dozen lines or so)
>> > for
>> > themselves.
>>
>> Except that oe-core still contains qemuarm which is armv5t and
>> almost
>> nobody is building it with thumb enabled in DISTRO config.
>
> Right, and the point I was trying to make is that, in this day and age,
> it's not obvious that supporting Thumb1 is an important goal for oe-
> core (because Thumb1 is sufficiently limited in both capabilities and
> performance that anybody who wants Thumb-state will be using a Thumb2
> capable cpu, and anybody who is stuck with an older cpu will be using
> ARM-state).
>
> If nobody, or almost nobody, is actually building a Thumb1
> configuration then this would seem to indicate that this is just an
> obsolete technology and nobody would mind very much if support for it
> were removed from oe-core.

I also vote for option 3.

All the good work and effort that Martin has been doing keeping the
Thumb1 builds alive could then perhaps be redirected to testing Thumb2
(or some other case which isn't covered by the default oe-core CI
builds).

> p.
>