The pipe2() was added to Linux in version 2.6.27. It is a variant of the normal pipe syscall, but takes an extra flags argument which can be the ORed value of O_NONBLOCK and O_CLOEXEC. The original pipe syscall is now defined as like the pipe2 syscall, but with the flags variable set to zero. Should we support this (in syscall2.stp) as an extra syscall, or should we retrofit the syscall.pipe probe alias to also match sys_pipe2?
I decided to add it as a new syscall.pipe2 variant since it is a real new syscall. commit 8bd0f6dce9effdb8bde2fb2cc6ab2c68be8d32d7 Author: Mark Wielaard <mjw@redhat.com> Date: Fri Mar 19 13:00:50 2010 +0100 PR11402 Support pipe2 syscall. The pipe2() was added to Linux in version 2.6.27. It is a variant of the normal pipe syscall, but takes an extra flags argument which can be the ORed value of O_NONBLOCK and O_CLOEXEC. * tapset/aux_syscalls.stp (_sys_pipe2_flag_str:string): New helper function. * tapset/syscalls2.stp (syscall.pipe2, syscall.pipe2.return): New probes.
And after some testing and discussions on irc I merged them into one syscall.pipe again: commit 7a95843846ea6a5f626dfeb63a26477e1f228dc4 Author: Mark Wielaard <mjw@redhat.com> Date: Fri Mar 19 16:53:19 2010 +0100 Merge syscall.pipe and syscall.pipe2 to get around "nesting". * tapset/syscalls2.stp (syscall.pipe[2][.return]): Merge into syscall.pipe and syscall.pipe.return. Set name according to flags. It is not really possible to easily get around the nesting of these syscalls. So just pretend there is only one pipe syscall for now. Also a new testcase for all this was added.