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

[Dmitry V. Levin]

On Tue, Feb 25, 2014 at 05:19:57PM -0600, James Yang wrote:
> 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.

I've committed the short form.  Thanks!


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140226/609f96de/attachment.bin>