Patch for -mcaller-super-interworking & stack arguments

Richard Earnshaw
Fri Aug 27 16:22:00 GMT 2004

On Fri, 2004-08-27 at 16:35, Daniel Jacobowitz wrote:
> On Fri, Aug 27, 2004 at 12:04:55PM +0100, Richard Earnshaw wrote:
> > On Mon, 2004-08-09 at 08:03, Richard Sandiford wrote:
> > > -mcaller-super-interworking causes all indirect calls to use an
> > > _interwork_call_via_rN stub.  If the target address is an ARM function,
> > > this stub will push the (thumb) return address onto the stack and get
> > > the ARM function to return to _arm_return instead.
> > > 
> > > Unfortunately, pushing the return address onto the stack means that thumb
> > > functions can't pass stack arguments to ARM functions.  The suggested fix
> > > is to define alternative interworking functions that store the return
> > > address at [r7, #-4] instead.  This of course requires the caller to
> > > use a frame pointer and to provide appropriate scratch space there.
> I was curious how non-indirect calls handled this situation, and whether this
> change would affect the linker, so I took a look.  My interpretation is that:
>   (A) the --support-old-code functionality of the COFF and PE backends
>       would need a matching update.  I don't know how this would work
>       since Richard's patch decides when compiling the caller whether
>       to stash it at [r7, #-4] or not.
>   (B) None of this has ever worked for ELF, since GNU ld has only about
>       half of the code necessary to build the right stubs.
> So right now the only options are to use -mcaller-super-interworking and
> restrict all calls to be via function pointers, or fix these shortcoming
> of the linker.  Am I reading the code right?

Quite likely.  My recent experiments with Thumb code on NetBSD/ARM
showed that I could only get things working correctly if I compiled all
Thumb code with -march=armv5t -mthumb -mlong-calls.  If I didn't do that
the linker would not insert correct interworking veneers.  I'd assumed
that this was because a mix of objects that were non-interworking and
interworking (being armv5 objects there's actually no difference, but
the linker's not smart enough to know that).


More information about the Gcc-patches mailing list