[oe] Making thumb builds easier in OE

[Koen Kooi]

On 26-10-2008 20:13, Phil Blundell wrote:
> On Sat, 2008-10-25 at 13:35 +0200, Koen Kooi wrote:
>> Hi,
>>
>> I noticed that Phil fixed thumb interworking in glibc for armv4t which
>> spurred me to do this:
>>
>> arm tune files: include tune-thumb by default
>> * it defaults to non-thumb, so no functional change
>
> Sadly it is not true to say that there is no functional change.
> Including tune-thumb.inc with no further changes will set interworking
> on by default: this is fairly transparent at ARMv5 and higher, but not
> for ARMv4T.  It is probably not a good idea to default interworking on
> for the latter architecture, which is to say that I think your changes
> to tune-arm920t.inc and tune-arm9tdmi.inc should probably be undone.
> (The same might be true for others: for example, I'm not sure offhand
> what architecture ep9312 uses.)

Right, I made interworking opt-in as well, I got thrown off by the 
ARM_INSTRUCTION set on top. ep9312 uses an arm920t core + maverick FPU.

regards,

Koen


>
>> So people can now set ARM_INSTRUCTION_SET = "thumb" and resulting ARM
>> builds will be in thumb mode.
>>
>> This does raise a few issues:
>>
>>    1) How can we handle thumb2? I only changed the arm9 and arm11 tune
>> files, how should we do the arm1176 and cortex ones?
>
> I'm not really sure what sort of 'handling' you are thinking of here.
> Can you elaborate?
>
>>    2) Since thumb packages are compatible with non-thumb ones we don't
>> really need a seperate arch, but keeping them same feels wrong and is a
>> QA nightmare.
>
> I'm not sure that this is any worse than, say, -O2 vs -Os vs -O0, or
> using different compilers.  There are already plenty of ways you can get
> different output binaries in a way that isn't reflected in PACKAGE_ARCH,
> and I have no real desire to see PACKAGE_ARCH become a sort of sha1 hash
> of everything that went into the build environment.  Ultimately, I think
> this is just something that DISTROs need to be grown-up about: they
> should pick a set of policies for each nominal architecture, stick to
> them, and be responsible for QAing any interoperability issues that
> arise if they decide to change.
>
> p.