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 <[email protected]> > > > > > --- > > > > > 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
pgpQb2Os2WYji.pgp
Description: PGP signature
------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
