Saving to 32 bits of GPRs in signal context

Arnd Bergmann arnd at arndb.de
Wed May 30 00:28:35 EST 2007


On Tuesday 29 May 2007, Segher Boessenkool wrote:
> > But it also makes me wonder about a few things:
> > - do you use the standard 32 bit ABI, in which case the caller of 
> > libraries
> >   does not care and the libraries can be put in the standard places,
> 
> The compiler should either a) use full 64-bit only for
> "volatile" (call-clobbered) registers, or b) save and
> restore other 64-bit mode registers around calls.  I don't
> remember if powerpc-linux-gcc does a) or b), if either.

As benh explained, the 64 bit register contents are maintained
over normal function calls, iirc the ABI treats the upper halves
of each register as call-clobbered.

The problem is really just signal handlers.

> > or are
> >   there cases where the ability to pass 64 bit values in a single
> >   register would improve performance to the point that it is worth
> >   having an incompatible library (where to put it and how to name it)?
> 
> That would be a third ABI.  Is it worth that?

no ;-)

> > - how can an application know that it can use 64 bit registers and call
> >   the optimized routines?
> 
> Just call them and trap the SEGV ;-)  You can check the
> aux vector of course, or ask glibc -- but the SEGV way
> is the only really portable way.  Strange world :-)

shouldn't that be SIGILL?

> > As long
> > as such an option does not exist, the usefulness of this feature is
> > somewhat limited. In other words, GCC for now has support for ILP32 and
> > LP64 modes, but it would be better to also have support for IP32L64.
> 
> ILP32LL64.  The C "mode" stays the same, only the generated
> machine insns are changed.

right, as mentioned before, IP32L64 would imply introducing a new
ABI, which we don't want.
 
	Arnd <><



More information about the Linuxppc-dev mailing list