develooper Front page | perl.perl5.porters | Postings from July 2012

Re: [perl #113980] [PATCH] pp_syscall: "I32 retval" truncates thereturned value

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
July 26, 2012 12:02
Subject:
Re: [perl #113980] [PATCH] pp_syscall: "I32 retval" truncates thereturned value
Message ID:
20120726190208.GL9583@plum.flirble.org
On Thu, Jul 26, 2012 at 09:59:49AM -0700, Father Chrysostomos via RT wrote:
> On Thu Jul 26 09:19:42 2012, nicholas wrote:

> > The sparc linux build is still ongoing...
> > (I think this is a 32 build on a sparc64 system. The machine is slow,
> > and I'm
> > not going to interrupt it to find out out for sure)

However, the 4 core MIPs box is faster. And on it,

$ ./perl -I../lib op/syscall-113980.t
1..1
not ok 1 - syscall retval is not truncated
# Failed test 1 - syscall retval is not truncated at op/syscall-113980.t line 26
#      got "-1"
# expected "2147434496"

> > I've not yet tried coaxing a build with -m32 on x86_64

... -Accflags=-m32 -Aldflags=-m32 -Alddlflags=-m32\ -shared

[and I don't know why I need to add -shared - is the hints file buggy?]

$ ./perl -I../lib op/syscall-113980.t
1..1 
not ok 1 - syscall retval is not truncated 
# Failed test 1 - syscall retval is not truncated at op/syscall-113980.t line 26 
#      got "-1" 
# expected "4160614400"

(output of ./perl -pe0 /proc/self/maps >maps attached)

> Thank you.  That means the skip is not being triggered.  Do you know how
> to test that this is a 64-bit linux system?  Or is this bug something we
> just can't reliably test?

No, I don't for sure. I think if one is sure it's Linux, run uname -m

eg

$ uname -m
x86_64
$ uname -m
mips64
$ uname -m
sparc64

vs

$ uname -m
i686
$ uname -m
armv6l

I think all the 64 bit architectures happen to match /64$/
However, I suspect that syscall numbers vary with architecture, and arguments
might too, so it's not going to be safe to use a hardcoded magic number
even on systems which seem to be 64 bits - really, check if it's exactly
x86_64. This also assumes that syscall numbers do not change on Linux.
I guess that they can't now, given that 3.x.y is really just 2.6.z, but I
presume that they can be deprecated and eventually dropped.

But as the above demonstrates, it would need to be a 64 bit process on a 64
bit OS. I think the latter is fairly easy - $Config{ptrsize}.

> Obviously calling stime is no good, even if it only works under root. 
> Running tests under root should not set the system time. :-)

For starters, I think skip it if running as root.
But yes, also skip unless it's linux, skip unless it's x86_64, and skip
unless it's a 64 bit build.

But I'm not confident how safe or reliable this sort of thing is ever going
to be.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About