Re: ARM thumb interworking hole?

[Charles Manning <manningc2 at actrix dot gen dot nz>]

On Wednesday 12 January 2005 06:48, Richard Earnshaw wrote:
> On Tue, 2005-01-11 at 16:12, Ian Lance Taylor wrote:
> > Charles Manning <manningc2@actrix.gen.nz> writes:
> > > 2) Why do we need the call_via_rx stub anyway? It seems to me this is
> > > only required if the target address is ARM code that does not return
> > > via a "bx lr". Surely we should be able to assume that if the code is
> > > marked as interworking code, then straght interworking will do the job.
> >
> > The problem is that ARMv4 Thumb code did not support blx.  The only
> > way to jump to an address held in a register was bx.  It would be
> > possible to use a two-instruction sequence (mov lr, pc; bx reg)
> > instead.
>
> No, because it doesn't work:
>
> 	mov lr, pc
>
> strips the Thumb bit.  That is, it really does give you '.+4' rather
> than the '.+5' that's needed for a return value.
>

That's correct, but this is **only** required if the target address of the 
jump is  not interworking code. ie the whole point of the stub is to be safe 
for non-interworking-savvy called code.

Surely if  the calling code is compiled with -mthumb-interwork and no other 
interworking flags we can assume that the called code is also 
interworking-savvy and will return with 'bx lr' (ie there is no need for the 
"safety stub").


>From where I stand (ie. almost totally ignorant of gcc's guts), the way code 
should be generated for handling a function pointer under vanilla 
interworking is something along the lines of


        mov   rx,....  @ load rx with pointer
        bl      call_rx_trampoline 
        .......

call_rx_trampoline:
         bx  rx

The rx_trampoline is very cheap (2 bytes) but needs to be close so it matters 
little if this is emitted for every section that uses it. I'm sure the 
compiler could emit this along the same lines as used to manage literal pools 
etc.

-- Charles