Patch for -mcaller-super-interworking & stack arguments
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