This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ColdFire 53/63] Static chain fixes
- From: Jeffrey Law <law at redhat dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Paul Brook <paul at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, Richard Sandiford <richard at codesourcery dot com>
- Date: Wed, 10 Jan 2007 15:05:37 -0700
- Subject: Re: [ColdFire 53/63] Static chain fixes
- References: <200701102151.l0ALpMgs032669@localhost.localdomain>
- Reply-to: law at redhat dot com
On Wed, 2007-01-10 at 16:51 -0500, Andrew Pinski wrote:
> >
> > On Wed, 2007-01-10 at 21:32 +0000, Paul Brook wrote:
> > > > > * config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro.
> > > > > (INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM.
> > > > > (__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME.
> > > > > * config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override.
> > > > > (M68K_STATIC_CHAIN_REG_NAME): Likewise.
> > > > > * config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise.
> > > > >
> > > > > gcc/testsuite/
> > > > > 200x-xx-xx Nathan Sidwell <nathan@codesourcery.com>
> > > > >
> > > > > * gcc.c-torture/execute/nestfunc-7.c: New.
> > > >
> > > > Isn't this an ABI change? If so it needs to be documented at the least
> > > > so that users of the m68k elf port aren't caught by surprise.
> > >
> > > I thought STATIC_CHAIN_REGNUM was an internal implementation detail.
> > > It's a private interface between the trampoline and the nested function, and
> > > never escapes to the outside world.
> > Doesn't the caller need to tell the callee where to find stacked
> > variables? It seems to me the caller and callee need to agree on
> > that location.
>
> Yes they have to agree but the only place which uses static chain are for
> nested functions and nested functions are always local to the TU.
Why must they be local.
Take the address of a nested function and pass it as an argument to a
function outside the current translation unit. IIRC the only
restriction we've made on calling nested functions is that the
container function must still be on the dynamic call stack.
jeff