Saving to 32 bits of GPRs in signal context

[Kumar Gala]

On May 29, 2007, at 3:05 AM, 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...
>
> 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.

This is all problematic since some 64-bit implementations may not  
guarantee the upper bits are valid when in 32-bit mode.  Look at the  
'Computation Modes' section in the architecture specs 2.03 or greater  
for embedded processors.

- k