This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] tst-clone3: Use __NR_futex_time64 if we don't have __NR_futex
On Fri, Jan 31, 2020 at 1:47 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Jan 31, 2020 at 6:10 PM Alistair Francis
> <alistair.francis@wdc.com> wrote:
> >
> > We can't include sysdep.h in the test case (it introduces lots of
> > strange failures) so __NR_futex isn't redifined to __NR_futex_time64 by
> > 64-bit time_t 32-bit archs (y2038 safe).
> >
> > To allow the test to pass let's just do the __NR_futex_time64 syscall if
> > we don't have __NR_futex defined.
> > ---
> > sysdeps/unix/sysv/linux/tst-clone3.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/sysdeps/unix/sysv/linux/tst-clone3.c b/sysdeps/unix/sysv/linux/tst-clone3.c
> > index 400eb89a5b..613cb4a811 100644
> > --- a/sysdeps/unix/sysv/linux/tst-clone3.c
> > +++ b/sysdeps/unix/sysv/linux/tst-clone3.c
> > @@ -56,7 +56,11 @@ f (void *a)
> > static inline int
> > futex_wait (int *futexp, int val)
> > {
> > +#ifdef __NR_futex
> > return syscall (__NR_futex, futexp, FUTEX_WAIT, val);
> > +#else
> > + return syscall (__NR_futex_time64, futexp, FUTEX_WAIT, val);
> > +#endif
> > }
>
> There are other references to __NR_futex and INTERNAL_SYSCALL (futex, ...)
> that likely suffer from the same problem. Would it make sense to address
> those all at once?
This is normally handled by something like this:
# ifndef __NR_futex
# define __NR_futex __NR_futex_time64
# endif
in sysdep.h.
This test is the only case I have seen where sysdep.h isn't included
(and I couldn't easily include it) hence the manual fixup.
Alistair
>
> Arnd