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. > 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. -- ldv
pgpVxcvNhQ2kN.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
