Saving to 32 bits of GPRs in signal context

[Steve Munroe]

Kumar Gala <galak at kernel.crashing.org> wrote on 05/29/2007 07:43:05 PM:

>
> On May 29, 2007, at 6:46 PM, Olof Johansson wrote:
>
> > On Wed, May 30, 2007 at 07:32:33AM +1000, Benjamin Herrenschmidt
> > wrote:
> >> On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
> >>> 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.
> >>
> >> Yuck. Well, we might need to export a spearate CPU feature bit to
> >> indicate that it's the case then.
> >
> > No need for a new bit, you should be able to key off of PPC_FEATURE_64
> > && !PPC_FEATURE_BOOKE.
>
> Nope, the architecture allows embedded to behave like server parts
> and support the full 64-bit registers.  We really should have a new
> feature bit so that if someone has an implementation of an embedded
> part that supports the functionality, they get the benefit.
>
When such exists we can add a bit, until then we can wait. The current
32-bit AT_HWCAP is almost full. so we should not allocate bits on
speculation.

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center