Re: Saving to 32 bits of GPRs in signal context

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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...

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. 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.

Ben.