Re: ARM thumb interworking hole?

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

On Friday 14 January 2005 01:27, Richard Earnshaw wrote:
> 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.

Sorry I misread. The safety stub thing is for interworked_vall_via_rx .


>
> 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).

Great. 
This sounds to me exactly like what I was trying to get at - without 
articulating it clearly. It will fill the current hole of not being able to 
use long calls together with call_via_rx() [which is really a kludge]. Fixing 
it this way is far neater than trying to make call_via_rx and long-calls work 
together (would need two registers ... one for the long call and one for rx).

-- CHarles