Preparing for the next release: call for testing

[Mike Frysinger]

On 15 Dec 2015 00:03, Dmitry V. Levin wrote:
> On Mon, Dec 14, 2015 at 03:45:40PM -0500, Mike Frysinger wrote:
> > On 11 Dec 2015 06:30, Dmitry V. Levin wrote:
> > > On Thu, Dec 10, 2015 at 09:37:35PM -0500, Mike Frysinger wrote:
> [...]
> > > > vFAIL:  test;   x86_64  32-bit/LSB  linux-4.1.6         kernel-headers-4.1.0   glibc-2.21  gcc-4.9.2
> > > > < times({tms_utime=22, tms_stime=17, tms_cutime=33, tms_cstime=26}) = 18446744071580810102
> > > > ---
> > > > > times({tms_utime=22, tms_stime=17, tms_cutime=33, tms_cstime=26}) = 2166225782
> > > 
> > > Looks like a sign extension bug in libc.
> > > Is there any safe way on x32 to call times(2) directly?
> > 
> > time_t/clock_t/unsigned long long are 64bit in x32.
> 
> Yes, but the value returned by times syscall in this case is 2166225782.
> I suppose it's libc that sign-extended 2166225782 to 18446744071580810102.
> That's why I'd like to avoid libc wrapper and call times syscall
> directly.  Unfortunately, syscall() returns long which is not appropriate
> for times syscall on x32.

yes, it looks like a bug in glibc.  i'll follow up with them.

wrt syscall, i vaguely recall i raised that issue a while back,
but not sure what happened to it.  i'll have to dig it up again.

> > looks like strace doesn't like it when you call clock_gettime:
> > strace: syscall_228(...) in unsupported 64-bit mode of process PID=2565
> > 
> > which doesn't make sense as they're the same syscall for x86_64 and x32.
> 
> They are not exactly the same, as x32 syscalls have __X32_SYSCALL_BIT set.
> In this case libc must be invoking an x86_64 syscall instead of an x32 one.

strace should handle all the syscalls that are common between the two ABIs.
they literally route to the same location and process args in the same way.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20151214/7752e670/attachment.bin>