[oe] Making thumb builds easier in OE

[Phil Blundell]

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.)

> 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.