Saving to 32 bits of GPRs in signal context

[Gabriel Paubert]

On Tue, May 29, 2007 at 06:05:00PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 03:52 -0400, Dan Malek wrote:
> > > I've been looking at saving & restoring the top 32 bits of 64 bits
> > > registers when delivering signals to 32 bits processes on a 64 bits
> > > kernel. The principle is easy, but I wonder where to stick them.
> > 
> > I'm wondering why you need to do this at all?
> > Why would a 32-bit application care about or
> > know what to do with these?
> 
> There are regular demands for the ability to use the full 64 bits
> registers in 32 bits applications when running on a 64 bits processor.
> That ranges from, iirc, the java folks, to people wanting to optimize
> some libs to use 64 bits registers internally when called from 32 bits
> apps etc...

My thoughts exactly, that's a very useful mode for some applications,
either loading a different library or having alternate routines depending 
on the availability of 64 bit GPRs for "long long" integer computations,
block copying and initializing (and therefore struct copies and memset()), 
etc... 

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, 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)? 
  
  I'd rather lean towards the first solution but I don't have enough
  data to judge. 

- how can an application know that it can use 64 bit registers and call
  the optimized routines?


Finally, I've not seen a compiler (well, GCC, but I don't have 4.2 or 
4.3 installed yet) that allows you to tell the compiler to use 32 bit
addresses but assume that integer registers are 64 bit wide. 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.

[...]

Well, after downloading the gcc trunk, it still seems to be the case.

Adding the IP32L64 mode des not seem to be such a huge project
(comparable to many Google SoC ones, but it's too late for 2007),
the problem is taht if it is started now, I don't think it will hit
an official GCC release before 2009 at the earliest.

> 
> You can use the full 64 bits easily on powerpc, ld/std just work, it's
> only the flags calculations and branches, mostly, that are truncated
> when running in 32 bits mode.

Only the implicit flags calculations, cmp has both 32 and 64 bit
versions, so it's not _that_ bad. However multiprecision arithmetic will 
have to be done in 32 bit mode because the carry setting[1] is linked 
with the mode (well I seem to remember a variant of the architecture 
which had 32 and 64 bit variants for generating the flags, but it was a 
long time ago. I've not seen support for this hybrid monster in gcc's md
file and I don't know whether it ever saw the light).

> Also, the kernel syscall & interrupt
> entry/exit path will save & restore the full 64 bits.
> 
> The problem is when you use signals. The compat signal code for 32 bits
> apps will only save and restore the bottom 32 bits, thus an application
> using signals will potentially corrupt the top 32 bits, which can be a
> problem if, for example, it uses a library that has optimisations based
> on using the full 64 bits.
> 


> We don't intend to update jmpbuf, getcontext/setcontext etc... for
> those... they are purely call clobbered etc..., but it would be nice if
> at least the signal frame save/restore could properly deal with them so
> they don't get randomly clobbered.

Have you considered the case of a mixed (IP32L64) mode calling a pure
32 bit library (or a user provided callback). The high part of R13-R31
will also be clobbered. Therefore the caller has to save and restore 
all registers that are live around the call, which results in
significant code bloat and needs compiler support.

All of this of course unless all people who write mixed mode code
are masochistic enough to limit themselves to 100% pure assembly... 

	Gabriel

[1] and overflow but sadly nobody cares about it, look at Ada code compiled 
when checking for overflows and get deeply depressed :-(


> 
> Ben.
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev