Re: thumb-2 and crt0.S init_hooks

[Richard Earnshaw <rearnsha at arm dot com>]

On Thu, 2008-12-18 at 16:06 -0200, Alexandre Pereira Nunes wrote:
> Hi,
> 
> It seems that there's a problem with the patch suggested on
> http://sourceware.org/ml/newlib/2008/msg00500.html.
> 
> This sort of constructs:
> 
> +#if defined(__thumb__) || defined(__thumb2__)
> +	blx   r3
> +#else
>  	mov	lr, pc
>  	mov	pc, r3
> +#endif
> 
> Will probably fail on armv4t targets. The reason is that this
> architecture lacks support for the blx instruction.
> Also, on thumb1 targets, mov lr, pc will do right thing, because the
> calling code is in arm mode, but the mov pc, r3 may fail to call a
> thumb function.

Indeed.

> 
> The way I see it, this sequence will probably work fine:
> 
> 
> +#if defined(__thumb2__)
> +	blx   r3
> +#else
>  	mov	lr, pc
>  	bx r3
> +#endif
> 
> 
> But there's still a catch on armv4t targets, if the code is compiled
> with -mno-thumb-interwork (default for arm-elf targets, but not for
> arm-*-eabi ones): some gcc versions tends to emit mov pc, lr or
> similar sequences in order to return from thumb functions, and on this
> case, a thunk has to be implemented to manually switch from thumb to
> arm mode since the processor is unable to do this by itself.

Nope, not right either...  

1) Pre-armv4t doesn't have BX.
2) in Thumb state, mov lr, pc doesn't work as expected, because the T
bit is stripped out of the PC value.
3) On armv5t or later, there is a blx instruction in both ARM and Thumb
code; when this exists, it's always preferable to the the
two-instruction alternative.

R.