Bug#518921: i386 missing syscall detection is broken on amd64
Linux commit c09249f8d1b84344eca882547afdbffee8c09d14 in v2.6.29-rc4 fixes
a bug that is completely breaking glibc's missing syscall detection for
i386 binaries on x86_64. This bug affects all kernels between v2.6.26 and
One of the symptoms of this bug is that when i386 binaries compiled on
newer systems use the popen() call, which attempts to detect the new
pipe2() syscall in v2.6.27, the subprocess will output to a random file
descriptor (typically stdout) instead of the pipe; see
<https://launchpad.net/bugs/339743>. There are likely to be more and more
problems as new syscalls get implemented.
I have verified that this patch applies on kernel 2.6.26 and fixes the
problem. Please apply it to the Debian kernel.
>From c09249f8d1b84344eca882547afdbffee8c09d14 Mon Sep 17 00:00:00 2001
From: Roland McGrath <email@example.com>
Date: Fri, 6 Feb 2009 18:15:18 -0800
Subject: [PATCH] x86-64: fix int $0x80 -ENOSYS return
One of my past fixes to this code introduced a different new bug.
When using 32-bit "int $0x80" entry for a bogus syscall number,
the return value is not correctly set to -ENOSYS. This only happens
when neither syscall-audit nor syscall tracing is enabled (i.e., never
seen if auditd ever started). Test program:
/* gcc -o int80-badsys -m32 -g int80-badsys.c
Run on x86-64 kernel.
Note to reproduce the bug you need auditd never to have started. */
asm ("int $0x80" : "=a" (res) : "0" (99999));
printf ("bad syscall returns %ld
return res != -ENOSYS;
The fix makes the int $0x80 path match the sysenter and syscall paths.