This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v4 03/24] sysdeps/gettimeofday: Use clock_gettime64 if avaliable
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alistair Francis <alistair dot francis at wdc dot com>
- Cc: <libc-alpha at sourceware dot org>, <arnd at arndb dot de>, <adhemerval dot zanella at linaro dot org>, <fweimer at redhat dot com>, <palmer at sifive dot com>, <macro at wdc dot com>, <zongbox at gmail dot com>, <alistair23 at gmail dot com>
- Date: Mon, 12 Aug 2019 17:27:21 +0000
- Subject: Re: [RFC v4 03/24] sysdeps/gettimeofday: Use clock_gettime64 if avaliable
- Ironport-sdr: b8YNO/xEwS2ebTo67l5Ej4J+dfigLY1N40hDy7utIcSDgIgNm9rA6CLZ+0nnbK1eNj+1pxcZ7V 0/5svkq13FL8thd7uyp+eqjlJDxT9cp1cqX1MHuK5IdG+uO1UBnCEOevQgoVYWJCud+Nr14h8c BwV83kHbmg/Upo6SfNjZFn3BVpTEAPl1bWF+HM7yjkgVXbVqA5Jpk2wr/wUrEm+lHQXL4bbUnK ZAcjaGIJJfE8ShUDdPLb9GOvI7Qc0dkWGy3MseIKpLFcQVrXLIooz9TMaYslmCDihUgbNDAY+H sz4=
- Ironport-sdr: bQmwCgKHpxXfR2+0BspUoOFS5UuyzdMGG7L3P6y+JyO4Hdlde6BuKN7jzfls8dNxzntYoL+HwA FJ/hQ7inpRpQB9qgCzQelNPD/XOtyKepIF67raCjkDskLXeqaGwUP9Ijl+lkGkTExkukoO+1rX RJWhs712Ia7i/tL8NmO2JaWDHiNPNs6Nl/ybK9xnOQ5xtV+JHo3ofCWuDdUQWPiY7rSV+1w4nq BfuZw/Z7HvPHu5yYakg/siRT73+unO3+SJtvfQJFAEyhaSTrQ37PJwGrMhiE9FYjIgCN8RO+tI gFE=
- References: <cover.1565398513.git.alistair.francis@wdc.com> <1561c94daae983eb2380b9579d737146505f1a6f.1565398513.git.alistair.francis@wdc.com>
On Fri, 9 Aug 2019, Alistair Francis wrote:
> The Linux documentation says that "The use of the timezone structure
> is obsolete; the tz argument should normally be specified as NULL."
The relevant information to include in commit messages here isn't what the
documentation says, it's what the interfaces actually do, as detailed in
<https://sourceware.org/ml/libc-alpha/2019-07/msg00574.html>.
> __gettimeofday (struct timeval *tv, struct timezone *tz)
> +#ifdef __ASSUME_TIME64_SYSCALLS
> + long int ret;
> + struct timespec now;
> +
> + ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> + &now);
This is using a timespec (possibly 32-bit) with a syscall that requires
the 64-bit version. You need to address such issues throughout the patch
series. As illustrated here, it's not just cases where you have a
mismatch with the function interface; you need to make sure, in every
case, that where you pass internal variables to 64-bit time syscalls they
have the correct type as well.
> +#else
> +# ifdef __NR_clock_nanosleep_time64
No, this code isn't using clock_nanosleep_time64. The #ifdef should be
for the syscall it actually uses.
--
Joseph S. Myers
joseph@codesourcery.com