Preparing for the next release: call for testing

Dmitry V. Levin ldv at
Wed Dec 16 00:50:20 UTC 2015

On Mon, Dec 14, 2015 at 04:45:33PM -0500, Mike Frysinger wrote:
> On 15 Dec 2015 00:03, Dmitry V. Levin wrote:
> > On Mon, Dec 14, 2015 at 03:45:40PM -0500, Mike Frysinger wrote:
> > > 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.

Should it?  Even if syscalls are the same on the kernel side, they often
look differently from 64-bit and 32-bit userspace point of view.
Most parsers assume that syscall arguments are of type long and accessible
via tcb.u_arg[], which is not the case for x86_64 syscalls on x32.
It would be a herculean task to convert them all to use tcb.ext_arg[]
on x32 (and all the rest to use __kernel_long_t instead of long).

That is, the diagnostics is correct, x86_64 syscalls are not supported on
x32 for this simple reason.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Strace-devel mailing list