O_CLOEXEC not handled in dup3 system call in user mode

In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag.

When the attached program runs, the expected output is:
errno=9=EBADF

How to reproduce on hppa:
- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa
- Set environment variables for running qemu-hppa.
- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa
errno=22=EINVAL
testdup3.c:54: assertion 'errno == EBADF' failed

How to reproduce on sparc64:
- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64
- Set environment variables for running qemu-sparc64.
- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64
errno=22=EINVAL
testdup3.c:54: assertion 'errno == EBADF' failed







I see this bug for hppa, sparc64.
I don't see it for m68k, mips, mips64, powerpc, powerpc64.
Most likely because the binary values of O_CLOEXEC on hppa and sparc64 are different than on other platforms. Looking in the glibc source code:

$ grep -r 'define.*O_CLOEXEC' glibc
glibc/bits/fcntl.h:# define O_CLOEXEC   0x00400000      /* Set close_on_exec.  */
glibc/sysdeps/mach/hurd/bits/fcntl.h:# define O_CLOEXEC 0x00400000 /* Set FD_CLOEXEC.  */
glibc/sysdeps/unix/sysv/linux/sparc/bits/fcntl.h:#define __O_CLOEXEC    0x400000 /* Set close_on_exit.  */
glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define __O_CLOEXEC   02000000
glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define O_CLOEXEC     __O_CLOEXEC     /* Set close_on_exec.  */
glibc/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h:#define __O_CLOEXEC     010000000 /* Set close_on_exec.  */
glibc/sysdeps/unix/sysv/linux/microblaze/bits/fcntl.h:#define __O_CLOEXEC        02000000       /* Set close_on_exec.  */
glibc/sysdeps/unix/sysv/linux/alpha/bits/fcntl.h:#define __O_CLOEXEC    010000000 /* Set close_on_exec.  */
glibc/sysdeps/nacl/bits/fcntl.h:# define O_CLOEXEC      02000000        /* Set close_on_exec.  */

So, what's missing is probably that the O_CLOEXEC of the target platform gets mapped to O_CLOEXEC of the host platform, during the dup3 system call emulation.

The behaviour in qemu-2.10 is the same as in qemu-2.9.

The behaviour in qemu-2.11 is the same as in qemu-2.9.

Should be fixed by http://patchwork.ozlabs.org/patch/849226/


Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=10fa993aae539fa8d0da1d

Confirmed: It's fixed in qemu-2.12.