Making thumb builds easier in OE

Making thumb builds easier in OE

[Koen Kooi]

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

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?

  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.

for 2) my first thought was to add '-thumb' to the archs, like angstrom 
adds '-oabi' for strongarm packages.

I'm not really interested in a discussion whether thumb(2) is worth it, 
I just want to solve the build- and distro side of it.

Thought suggestions?

regards,

Koen

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

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