[PATCH] powerpc64/linux: Fix 64-bit process detection on embedded

[James Yang]

On Tue, 25 Feb 2014, Dmitry V. Levin wrote:

> On Wed, Feb 19, 2014 at 07:10:53PM -0600, James Yang wrote:
> > On Thu, 20 Feb 2014, Dmitry V. Levin wrote:
> > 
> > > On Tue, Feb 18, 2014 at 03:32:43PM -0600, James Yang wrote:
> > > > * syscall.c: Fix 64-bit process detection on embedded powerpc
> > > > 
> > > > Signed-off-by: James Yang <james.yang at freescale.com>
> > > > ---
> > > >  syscall.c |    5 +++--
> > > >  1 files changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/syscall.c b/syscall.c
> > > > index 3477dcd..8d47e7e 100644
> > > > --- a/syscall.c
> > > > +++ b/syscall.c
> > > > @@ -1222,8 +1222,9 @@ get_scno(struct tcb *tcp)
> > > >  	int currpers;
> > > >  
> > > >  	/* Check for 64/32 bit mode. */
> > > > -	/* SF is bit 0 of MSR */
> > > > -	if ((ppc_regs.msr >> 63) & 1)
> > > > +	/* SF is bit 0 of MSR (a 64-bit register in Server) */
> > > > +	/* CM is bit 0 of MSR (a 32-bit register in Embedded) */
> > > > +	if (((ppc_regs.msr >> 63) & 1) || ((ppc_regs.msr >> 31) & 1))
> > > >  		currpers = 0;
> > > >  	else
> > > >  		currpers = 1;
> > > 
> > > In case of 64-bit MSR, that would be a test for 32th bit.
> > > I'm not quite familiar with ppc64, is there any risk for a false positive
> > > in this case?
> > 
> > When tested on a POWER7 running Linux, MSR bit 32 is clear.  So 
> > empircally, it is not in use.
> > 
> > It is documented as part of a reserved field according to Power ISA 
> > Book III-S so it should read as 0 unless there's an implementation- 
> > specific use of the bit.  No documentation I have found describes the 
> > use of it as other than reserved.
> 
> OK, let's assume it's safe to do the check this way.
> 
> There seems to be a shorter equivalent check for these two bits:
> 	ppc_regs.msr & 0x8000000080000000
>
> Which of them would you prefer, the longer one or the shorter one?


If bit 32 ends up being used by server someday for some meaning where 
it could be set for a 32-bit process, the long way will still be able 
to confidently identify a 64-bit process, but it will not confidently 
identify a 32-bit process.  The short way will have no confidence at 
all for either 32-bit or 64-bit.

The mask has better codegen as long as we make the assumption bit 32 
is reserved and will read as 0.

Until use of bit 32 becomes a reality (per above, I have no 
information that it will be used), I'd say using a mask is fine.