No thumb only support in uclibc?

[Paul Brook]

[Second attempt due to draconian miling list policy]
> I think i have touched this single spot now in master to be encoding
> agnostic (Paul added thumb2 in efce79f09ae6daa77cd322df0d532beec3f445f5 )
> but It seems to me it was/is not complete:
> From the looks there are a couple of spots setting the thumb bits on
> addresses that are written in arm mode, so you (resp. your thumb2 only v7
> cortex-m3) will trip.

It's worth noting that a lot of this code is extremely twisty, and doesn't 
necessarily behave as you might first expect.

There are several interesting levels of Thumb support:

1) ARMv4t: Use Thumb-1 (significantly reduces ISA) for code size. Usually 
switch back to ARM mode for anything complicated. Code often needs needs 
additional magic to make sure the mode switch happens correctly. Thumb mode 
missing some critical system level instructions.
1b) As (1) but don't bother trying to support both ARM and Thumb code in the 
same binary.  This was always a pretty sketchy idea, and I don't think anyone 
cares about this any more.
2) ARMv5/v6: As (1), but does not not need most of the additional magic for 
mode switching. This also applies to all later variants.
3) ARMv7-A/R: (aka Thumb-2) Thumb mode now includes most "Arm" instructions.  
In most cases the original arm assembly just works as Thumb code (and is 
smaller), or is easily modified to do so.
4) ARMv7-M: As (3), but you can't fall back to arm code if you get desperate.
5) ARMv6-M: Thumb-1 plus a few system instructions.  You have to rewrite all 
your old arm assembly, often taking a significant performance/quality hit. 
Often the solution is to ignore the optimized assembly altogether and just use 
the generic C implementation.

All further confused because these features were added in approximately the 
order above, without knowledge of later requirements.

This leads to fun macros[2] like REALLY_THUMB (switch_to_arm actually does 
nothing and leaves you in Thumb-2 mode),  THUMB1_ONLY (switch_to_arm is a hard 
error), and THUMB_INTERWORK *not* being defined on armv5+ despite those 
targets supporting interworking, etc

In addition various magic assembly directives are required to make Thumb entry 
points work correctly, some of which are not understood by crufty old 
toolchains. Anything that's manually mangling addresses is probably already 
broken :-/ The ARM EABI fixed a lot of this, but there's still a lot of 
(probably broken) legacy ABI support lurking to trip up the unwary.

I don't remember exactly what level of evil the uclibc port involves, but at 
the point it was submitted it definitely worked for all the above.

Paul

[2] I have probably got the exact names wrong. [lib]gcc and uclibc often spell 
the same thing different ways.