[5/7] linux: Use waitid on wait4 if __NR_wait4 is not defined
Commit Message
If the wait4 syscall is not avaliable (such as y2038 safe 32-bit
systems) waitid should be used instead. However prior Linux 5.4
waitid is not a fully superset of other wait instruction, since it
does not include support for waiting for the current process group.
It would be possible to emulate to issue an extra syscall to get
the current process group, but it is inherent racy: after the current
process group is received and before it is passed to waitid a signal
could arrive causing the current process group to change
So waitid is used if wait4 is not defined iff the build is
enabled with a minimum kernel if 5.4+. The new assume
__ASSUME_WAITID_PID0_P_PGID is added and an error is issued if waitid
can not be implemented by either __NR_wait4 or
__NR_waitid && __ASSUME_WAITID_PID0_P_PGID.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Co-authored-by: Alistair Francis <alistair.francis@wdc.com>
---
sysdeps/unix/sysv/linux/kernel-features.h | 6 ++
sysdeps/unix/sysv/linux/syscalls.list | 1 -
sysdeps/unix/sysv/linux/wait4.c | 88 +++++++++++++++++++++++
3 files changed, 94 insertions(+), 1 deletion(-)
create mode 100644 sysdeps/unix/sysv/linux/wait4.c
Comments
On Thu, Nov 14, 2019 at 9:47 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
> If the wait4 syscall is not avaliable (such as y2038 safe 32-bit
> systems) waitid should be used instead. However prior Linux 5.4
> waitid is not a fully superset of other wait instruction, since it
> does not include support for waiting for the current process group.
>
> It would be possible to emulate to issue an extra syscall to get
> the current process group, but it is inherent racy: after the current
> process group is received and before it is passed to waitid a signal
> could arrive causing the current process group to change
>
> So waitid is used if wait4 is not defined iff the build is
> enabled with a minimum kernel if 5.4+. The new assume
> __ASSUME_WAITID_PID0_P_PGID is added and an error is issued if waitid
> can not be implemented by either __NR_wait4 or
> __NR_waitid && __ASSUME_WAITID_PID0_P_PGID.
>
> Checked on x86_64-linux-gnu and i686-linux-gnu.
>
> Co-authored-by: Alistair Francis <alistair.francis@wdc.com>
> ---
> sysdeps/unix/sysv/linux/kernel-features.h | 6 ++
> sysdeps/unix/sysv/linux/syscalls.list | 1 -
> sysdeps/unix/sysv/linux/wait4.c | 88 +++++++++++++++++++++++
> 3 files changed, 94 insertions(+), 1 deletion(-)
> create mode 100644 sysdeps/unix/sysv/linux/wait4.c
>
> diff --git a/sysdeps/unix/sysv/linux/kernel-features.h b/sysdeps/unix/sysv/linux/kernel-features.h
> index e6be76ff46..43faaa3f9d 100644
> --- a/sysdeps/unix/sysv/linux/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/kernel-features.h
> @@ -208,4 +208,10 @@
> # define __ASSUME_TIME64_SYSCALLS 1
> #endif
>
> +/* Linux waitid prior kernel 5.4 does not support waiting for the current
> + process group. */
> +#if __LINUX_KERNEL_VERSION >= 0x050400
> +# define __ASSUME_WAITID_PID0_P_PGID
> +#endif
> +
> #endif /* kernel-features.h */
> diff --git a/sysdeps/unix/sysv/linux/syscalls.list b/sysdeps/unix/sysv/linux/syscalls.list
> index 603e517ca6..5f1352ad43 100644
> --- a/sysdeps/unix/sysv/linux/syscalls.list
> +++ b/sysdeps/unix/sysv/linux/syscalls.list
> @@ -67,7 +67,6 @@ swapoff - swapoff i:s __swapoff swapoff
> unshare EXTRA unshare i:i unshare
> uselib EXTRA uselib i:s __compat_uselib uselib@GLIBC_2.0:GLIBC_2.23
> utime - utime i:sP utime
> -wait4 - wait4 i:iWiP __wait4 wait4
>
> chown - chown i:sii __libc_chown __chown chown
>
> diff --git a/sysdeps/unix/sysv/linux/wait4.c b/sysdeps/unix/sysv/linux/wait4.c
> new file mode 100644
> index 0000000000..d09917c7ff
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/wait4.c
> @@ -0,0 +1,88 @@
> +/* Wait for process to change state. Linux version.
> + Copyright (C) 2019 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
> + The GNU C Library is free software; you can redistribute it and/or
> + modify it under the terms of the GNU Lesser General Public
> + License as published by the Free Software Foundation; either
> + version 2.1 of the License, or (at your option) any later version.
> +
> + The GNU C Library is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + Lesser General Public License for more details.
> +
> + You should have received a copy of the GNU Lesser General Public
> + License along with the GNU C Library; if not, see
> + <https://www.gnu.org/licenses/>. */
> +
> +#include <sys/wait.h>
> +#include <sys/resource.h>
> +#include <sysdep-cancel.h>
> +
> +pid_t
> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
> +{
> +#if __NR_wait4
This needs to be #ifdef as __NR_wait4 doesn't exist on RV32.
Alistair
> + return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
> +#elif defined (__ASSUME_WAITID_PID0_P_PGID)
> + idtype_t idtype = P_PID;
> +
> + if (pid < -1)
> + {
> + idtype = P_PGID;
> + pid *= -1;
> + }
> + else if (pid == -1)
> + {
> + idtype = P_ALL;
> + }
> + else if (pid == 0)
> + {
> + idtype = P_PGID;
> + }
> +
> + options |= WEXITED;
> +
> + siginfo_t infop;
> + if (SYSCALL_CANCEL (waitid, idtype, pid, &infop, options, usage) < 0)
> + return -1;
> +
> + if (stat_loc)
> + {
> + switch (infop.si_code)
> + {
> + case CLD_EXITED:
> + *stat_loc = W_EXITCODE (infop.si_status, 0);
> + break;
> + case CLD_DUMPED:
> + *stat_loc = WCOREFLAG | infop.si_status;
> + break;
> + case CLD_KILLED:
> + *stat_loc = infop.si_status;
> + break;
> + case CLD_TRAPPED:
> + case CLD_STOPPED:
> + *stat_loc = W_STOPCODE (infop.si_status);
> + break;
> + case CLD_CONTINUED:
> + *stat_loc = __W_CONTINUED;
> + break;
> + default:
> + *stat_loc = 0;
> + break;
> + }
> + }
> +
> + return infop.si_pid;
> +# else
> +/* Linux waitid prior kernel 5.4 does not support waiting for the current
> + process. It would be possible to emulate it by calling getpgid for pid 0,
> + however, it would require an additional syscall and it is inherent racy:
> + after the current process group is received and before it is passed
> + to waitid a signal could arrive causing the current process group to
> + change. */
> +# error "The kernel ABI does not provide a way to implement wait4"
> +#endif
> +}
> +weak_alias (__wait4, wait4)
> --
> 2.17.1
>
On 15/11/2019 15:27, Alistair Francis wrote:
>> +
>> +pid_t
>> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
>> +{
>> +#if __NR_wait4
>
> This needs to be #ifdef as __NR_wait4 doesn't exist on RV32.
>
> Alistair
Acked.
On 14/11/2019 11:47, Adhemerval Zanella wrote:
> +pid_t
> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
> +{
> +#if __NR_wait4
> + return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
> +#elif defined (__ASSUME_WAITID_PID0_P_PGID)
[...]
> +# else
> +/* Linux waitid prior kernel 5.4 does not support waiting for the current
> + process. It would be possible to emulate it by calling getpgid for pid 0,
> + however, it would require an additional syscall and it is inherent racy:
> + after the current process group is received and before it is passed
> + to waitid a signal could arrive causing the current process group to
> + change. */
> +# error "The kernel ABI does not provide a way to implement wait4"
> +#endif
So the only design here that I am not sure is if the best one is to trigger
a build error to avoid an architecture to not define __NR_wait4 and also
support kernels older than 5.4 (which would not define
__ASSUME_WAITID_PID0_P_PGID), or if it should do as generic implementation
and return ENOSYS along with a stub.
Thoughts?
On Thu, Nov 21, 2019 at 9:53 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 14/11/2019 11:47, Adhemerval Zanella wrote:
> > +pid_t
> > +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
> > +{
> > +#if __NR_wait4
> > + return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
> > +#elif defined (__ASSUME_WAITID_PID0_P_PGID)
> [...]
> > +# else
> > +/* Linux waitid prior kernel 5.4 does not support waiting for the current
> > + process. It would be possible to emulate it by calling getpgid for pid 0,
> > + however, it would require an additional syscall and it is inherent racy:
> > + after the current process group is received and before it is passed
> > + to waitid a signal could arrive causing the current process group to
> > + change. */
> > +# error "The kernel ABI does not provide a way to implement wait4"
> > +#endif
>
> So the only design here that I am not sure is if the best one is to trigger
> a build error to avoid an architecture to not define __NR_wait4 and also
> support kernels older than 5.4 (which would not define
> __ASSUME_WAITID_PID0_P_PGID), or if it should do as generic implementation
> and return ENOSYS along with a stub.
>
> Thoughts?
I think a build error makes sense. Currently only RV32 doesn't have
__NR_wait4 (which isn't upstreamed) so you aren't breaking anything.
The only kernels that could possibly not have __NR_wait4 and be less
then 5.4 are 5.1, 5.2 and 5.3, non of which are stable so they will
slowly disappear anyway.
Not producing a build error could be very confusing for developers
that do get bitten by the missing implementation.
Alistair
On 21/11/2019 15:41, Alistair Francis wrote:
> On Thu, Nov 21, 2019 at 9:53 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 14/11/2019 11:47, Adhemerval Zanella wrote:
>>> +pid_t
>>> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
>>> +{
>>> +#if __NR_wait4
>>> + return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
>>> +#elif defined (__ASSUME_WAITID_PID0_P_PGID)
>> [...]
>>> +# else
>>> +/* Linux waitid prior kernel 5.4 does not support waiting for the current
>>> + process. It would be possible to emulate it by calling getpgid for pid 0,
>>> + however, it would require an additional syscall and it is inherent racy:
>>> + after the current process group is received and before it is passed
>>> + to waitid a signal could arrive causing the current process group to
>>> + change. */
>>> +# error "The kernel ABI does not provide a way to implement wait4"
>>> +#endif
>>
>> So the only design here that I am not sure is if the best one is to trigger
>> a build error to avoid an architecture to not define __NR_wait4 and also
>> support kernels older than 5.4 (which would not define
>> __ASSUME_WAITID_PID0_P_PGID), or if it should do as generic implementation
>> and return ENOSYS along with a stub.
>>
>> Thoughts?
>
> I think a build error makes sense. Currently only RV32 doesn't have
> __NR_wait4 (which isn't upstreamed) so you aren't breaking anything.
>
> The only kernels that could possibly not have __NR_wait4 and be less
> then 5.4 are 5.1, 5.2 and 5.3, non of which are stable so they will
> slowly disappear anyway.
>
> Not producing a build error could be very confusing for developers
> that do get bitten by the missing implementation.
>
My point if if checking for kernel version to define __ASSUME_WAITID_PID0_P_PGID
does make, meaning it is possible with some config option in the kernel
to enable only waitid for kernels older than 5.3; or if we can assume
some configuration in always invalid and thus the kernel won't allow
enable it.
If the latter we can then remove the __ASSUME_WAITID_PID0_P_PGID and
add a comment on waitid implementation stating that if waitid is the
only syscall supported then it is suppose to be the superset of all
wait* functionalities.
On Fri, Nov 22, 2019 at 4:15 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 21/11/2019 15:41, Alistair Francis wrote:
> > On Thu, Nov 21, 2019 at 9:53 AM Adhemerval Zanella
> > <adhemerval.zanella@linaro.org> wrote:
> >>
> >>
> >>
> >> On 14/11/2019 11:47, Adhemerval Zanella wrote:
> >>> +pid_t
> >>> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
> >>> +{
> >>> +#if __NR_wait4
> >>> + return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
> >>> +#elif defined (__ASSUME_WAITID_PID0_P_PGID)
> >> [...]
> >>> +# else
> >>> +/* Linux waitid prior kernel 5.4 does not support waiting for the current
> >>> + process. It would be possible to emulate it by calling getpgid for pid 0,
> >>> + however, it would require an additional syscall and it is inherent racy:
> >>> + after the current process group is received and before it is passed
> >>> + to waitid a signal could arrive causing the current process group to
> >>> + change. */
> >>> +# error "The kernel ABI does not provide a way to implement wait4"
> >>> +#endif
> >>
> >> So the only design here that I am not sure is if the best one is to trigger
> >> a build error to avoid an architecture to not define __NR_wait4 and also
> >> support kernels older than 5.4 (which would not define
> >> __ASSUME_WAITID_PID0_P_PGID), or if it should do as generic implementation
> >> and return ENOSYS along with a stub.
> >>
> >> Thoughts?
> >
> > I think a build error makes sense. Currently only RV32 doesn't have
> > __NR_wait4 (which isn't upstreamed) so you aren't breaking anything.
> >
> > The only kernels that could possibly not have __NR_wait4 and be less
> > then 5.4 are 5.1, 5.2 and 5.3, non of which are stable so they will
> > slowly disappear anyway.
> >
> > Not producing a build error could be very confusing for developers
> > that do get bitten by the missing implementation.
> >
>
> My point if if checking for kernel version to define __ASSUME_WAITID_PID0_P_PGID
> does make, meaning it is possible with some config option in the kernel
> to enable only waitid for kernels older than 5.3; or if we can assume
> some configuration in always invalid and thus the kernel won't allow
> enable it.
>
> If the latter we can then remove the __ASSUME_WAITID_PID0_P_PGID and
> add a comment on waitid implementation stating that if waitid is the
> only syscall supported then it is suppose to be the superset of all
> wait* functionalities.
I think I understand what you are saying.
It is NOT the case that if waitid is the only syscall supported then
it is a superset of all wait* functions.
For RV32 the 5.1, 5.2 and 5.3 only support waitid but do not support
the PID0 P_PGID functionality. In these three kernel cases the call
will fail.
Alistair
On 22/11/2019 17:00, Alistair Francis wrote:
> On Fri, Nov 22, 2019 at 4:15 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 21/11/2019 15:41, Alistair Francis wrote:
>>> On Thu, Nov 21, 2019 at 9:53 AM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 14/11/2019 11:47, Adhemerval Zanella wrote:
>>>>> +pid_t
>>>>> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
>>>>> +{
>>>>> +#if __NR_wait4
>>>>> + return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
>>>>> +#elif defined (__ASSUME_WAITID_PID0_P_PGID)
>>>> [...]
>>>>> +# else
>>>>> +/* Linux waitid prior kernel 5.4 does not support waiting for the current
>>>>> + process. It would be possible to emulate it by calling getpgid for pid 0,
>>>>> + however, it would require an additional syscall and it is inherent racy:
>>>>> + after the current process group is received and before it is passed
>>>>> + to waitid a signal could arrive causing the current process group to
>>>>> + change. */
>>>>> +# error "The kernel ABI does not provide a way to implement wait4"
>>>>> +#endif
>>>>
>>>> So the only design here that I am not sure is if the best one is to trigger
>>>> a build error to avoid an architecture to not define __NR_wait4 and also
>>>> support kernels older than 5.4 (which would not define
>>>> __ASSUME_WAITID_PID0_P_PGID), or if it should do as generic implementation
>>>> and return ENOSYS along with a stub.
>>>>
>>>> Thoughts?
>>>
>>> I think a build error makes sense. Currently only RV32 doesn't have
>>> __NR_wait4 (which isn't upstreamed) so you aren't breaking anything.
>>>
>>> The only kernels that could possibly not have __NR_wait4 and be less
>>> then 5.4 are 5.1, 5.2 and 5.3, non of which are stable so they will
>>> slowly disappear anyway.
>>>
>>> Not producing a build error could be very confusing for developers
>>> that do get bitten by the missing implementation.
>>>
>>
>> My point if if checking for kernel version to define __ASSUME_WAITID_PID0_P_PGID
>> does make, meaning it is possible with some config option in the kernel
>> to enable only waitid for kernels older than 5.3; or if we can assume
>> some configuration in always invalid and thus the kernel won't allow
>> enable it.
>>
>> If the latter we can then remove the __ASSUME_WAITID_PID0_P_PGID and
>> add a comment on waitid implementation stating that if waitid is the
>> only syscall supported then it is suppose to be the superset of all
>> wait* functionalities.
>
> I think I understand what you are saying.
>
> It is NOT the case that if waitid is the only syscall supported then
> it is a superset of all wait* functions.
>
> For RV32 the 5.1, 5.2 and 5.3 only support waitid but do not support
> the PID0 P_PGID functionality. In these three kernel cases the call
> will fail.
>
If it is the case (and it does seems linux support RV32 for kernel older
than v5.4), we will need to make the 5.4 the minimum supported kernel for
RV32 and any other architecture that only support waitid syscall.
The kernel check can be done at the configure level, but it does not
help on some kernel configuration for a architecture that explicit
try to remove olds syscall to mimic the generic user API (not sure if
this is possible with current kernel configuration flags).
So it seems that __ASSUME_WAITID_PID0_P_PGID should be a safe call to
avoid such theoretical scenarios. I will rework how the flag is used
to mimic other assume usage where newer kernel version undef the flag,
so it should be simpler to remove it once the minimum kernel is lifted.
On 25/11/2019 09:39, Adhemerval Zanella wrote:
> So it seems that __ASSUME_WAITID_PID0_P_PGID should be a safe call to
> avoid such theoretical scenarios. I will rework how the flag is used
> to mimic other assume usage where newer kernel version undef the flag,
> so it should be simpler to remove it once the minimum kernel is lifted.
>
In fact I think change the __ASSUME_WAITID_PID0_P_PGID won't be much
a improvement
On Mon, Nov 25, 2019 at 4:42 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 25/11/2019 09:39, Adhemerval Zanella wrote:
>
> > So it seems that __ASSUME_WAITID_PID0_P_PGID should be a safe call to
> > avoid such theoretical scenarios. I will rework how the flag is used
> > to mimic other assume usage where newer kernel version undef the flag,
> > so it should be simpler to remove it once the minimum kernel is lifted.
> >
>
> In fact I think change the __ASSUME_WAITID_PID0_P_PGID won't be much
> a improvement
Any update on this series?
Alistair
On 03/12/2019 15:58, Alistair Francis wrote:
> On Mon, Nov 25, 2019 at 4:42 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 25/11/2019 09:39, Adhemerval Zanella wrote:
>>
>>> So it seems that __ASSUME_WAITID_PID0_P_PGID should be a safe call to
>>> avoid such theoretical scenarios. I will rework how the flag is used
>>> to mimic other assume usage where newer kernel version undef the flag,
>>> so it should be simpler to remove it once the minimum kernel is lifted.
>>>
>>
>> In fact I think change the __ASSUME_WAITID_PID0_P_PGID won't be much
>> a improvement
>
> Any update on this series?
I am working on a libpthread-compat.c patch I plan to update, so I can
rebase against it.
@@ -208,4 +208,10 @@
# define __ASSUME_TIME64_SYSCALLS 1
#endif
+/* Linux waitid prior kernel 5.4 does not support waiting for the current
+ process group. */
+#if __LINUX_KERNEL_VERSION >= 0x050400
+# define __ASSUME_WAITID_PID0_P_PGID
+#endif
+
#endif /* kernel-features.h */
@@ -67,7 +67,6 @@ swapoff - swapoff i:s __swapoff swapoff
unshare EXTRA unshare i:i unshare
uselib EXTRA uselib i:s __compat_uselib uselib@GLIBC_2.0:GLIBC_2.23
utime - utime i:sP utime
-wait4 - wait4 i:iWiP __wait4 wait4
chown - chown i:sii __libc_chown __chown chown
new file mode 100644
@@ -0,0 +1,88 @@
+/* Wait for process to change state. Linux version.
+ Copyright (C) 2019 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <https://www.gnu.org/licenses/>. */
+
+#include <sys/wait.h>
+#include <sys/resource.h>
+#include <sysdep-cancel.h>
+
+pid_t
+__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
+{
+#if __NR_wait4
+ return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
+#elif defined (__ASSUME_WAITID_PID0_P_PGID)
+ idtype_t idtype = P_PID;
+
+ if (pid < -1)
+ {
+ idtype = P_PGID;
+ pid *= -1;
+ }
+ else if (pid == -1)
+ {
+ idtype = P_ALL;
+ }
+ else if (pid == 0)
+ {
+ idtype = P_PGID;
+ }
+
+ options |= WEXITED;
+
+ siginfo_t infop;
+ if (SYSCALL_CANCEL (waitid, idtype, pid, &infop, options, usage) < 0)
+ return -1;
+
+ if (stat_loc)
+ {
+ switch (infop.si_code)
+ {
+ case CLD_EXITED:
+ *stat_loc = W_EXITCODE (infop.si_status, 0);
+ break;
+ case CLD_DUMPED:
+ *stat_loc = WCOREFLAG | infop.si_status;
+ break;
+ case CLD_KILLED:
+ *stat_loc = infop.si_status;
+ break;
+ case CLD_TRAPPED:
+ case CLD_STOPPED:
+ *stat_loc = W_STOPCODE (infop.si_status);
+ break;
+ case CLD_CONTINUED:
+ *stat_loc = __W_CONTINUED;
+ break;
+ default:
+ *stat_loc = 0;
+ break;
+ }
+ }
+
+ return infop.si_pid;
+# else
+/* Linux waitid prior kernel 5.4 does not support waiting for the current
+ process. It would be possible to emulate it by calling getpgid for pid 0,
+ however, it would require an additional syscall and it is inherent racy:
+ after the current process group is received and before it is passed
+ to waitid a signal could arrive causing the current process group to
+ change. */
+# error "The kernel ABI does not provide a way to implement wait4"
+#endif
+}
+weak_alias (__wait4, wait4)