Re: ARM thumb interworking hole?

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Wed, 2005-01-12 at 23:36, Charles Manning wrote:
> 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").
> 

No, you've missed the point.  This is *nothing* to do with handling code
that is not interworking clean,  it's to do with ensuring that the link
register is set up correctly so that when interworking clean code in the
target does a return it will ensure that it re-enters *our* code in
Thumb state.  Our code is Thumb code, and so the link register must have
the least significant bit in it set, otherwise a 'bx lr' in the callee
will end up trying to return to us in ARM state, and that spells
disaster.

Anyway, this is substantially going to be fixed for the normal case when
I commit the patch I'm currently testing.  The problem on the EABI is
that __call_via_<regno> is not part of the official run-time support
library, so we need to code this a different way.  I'm going to fix this
by making the compiler synthesise the contents of a __call_via_reg call
in each object file that needs it.  Typically the cost of this will be
low (between 2 and 16 bytes per object file that uses indirect calls),
but there are cases where it can be a bit more expensive (functions in
their own sections generally need their own trampolines).

R.