This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for -mcaller-super-interworking & stack arguments


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?

-- 
Daniel Jacobowitz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]