This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Andreas Schwab <schwab at suse dot de>, Alistair Francis <alistair23 at gmail dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Florian Weimer <fweimer at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, Zack Weinberg <zackw at panix dot com>, Carlos O'Donell <carlos at redhat dot com>
- Date: Tue, 7 Jan 2020 09:36:45 -0300
- Subject: Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation
- References: <20200106121742.1628-1-lukma@denx.de> <ea1ea005-6dee-f8dd-f205-d0a47a952904@linaro.org> <20200107102752.396f7f6f@jawa>
On 07/01/2020 06:27, Lukasz Majewski wrote:
>> As a side note, now that arch-syscall patch is upstream should we
>> assume that for !__ASSUME_TIME64_SYSCALLS the __NR_timerfd_gettime64
>> should be defined (meaning that Linux supports time64 for all 32-bit
>> architectures)?
>
> Only Linux version >= 5.1 supports 64 bit time on archs with __WORDSIZE
> = 32. I do guess (but I may be wrong here) that the arch-syscall is
> supposed to reflect the exact syscalls provided by kernel headers used
> for building (to help with validation of Y2038 patches).
The arch-syscall is now autogenerated from the latest kernel release
defined in build-many-glibcs.py. So the question is whether Linux
support and enforces time64 support on all and future 32-bit
architectures or if there is still some missing ones (as it has
happen on some syscall additions, where some architecture lag
behind some releases).
>
>>
>>> + struct itimerspec its32;
>>> + int retval = INLINE_SYSCALL_CALL (timerfd_gettime, fd, &its32);
>>> + if (retval == 0)
>>> + {
>>> + value->it_interval = valid_timespec_to_timespec64
>>> (its32.it_interval);
>>> + value->it_value = valid_timespec_to_timespec64
>>> (its32.it_value);
>>> + }
>>> +
>>> + return retval;
>>> +#endif
>>> +}
>>
>>
>> Ok.
>>
>>> +
>>> +#if __TIMESIZE != 64
>>> +libc_hidden_def (__timerfd_gettime64)
>>
>> Ok.
>>
>> As a side note, we should fix it on clock_{get,set}time to add the
>> missing libc_hidden_def.
>
> The clock_gettime already has libc_hidden_def. The difference is that we
> use some compatibility code (after moving clock_gettime from librt to
> libc) instead of strong_alias (as it mimics the behavior from auto
> generated syscall wrapper).
I meant for the new time64 symbols. Currently it is not an issue because
the internal time64 symbol is not exported and static linker uses the
internal __GI_ name for the symbol. For instance, objdump -t on
clock_gettime.os on a 32-bit architecture (powerpc in this case) shows:
00000144 g F .text 00000088 __clock_gettime
00000144 g F .text 00000088 __clock_gettime_2
00000000 g F .text 00000144 .hidden __GI___clock_gettime64
00000144 g F .text 00000088 .hidden __GI___clock_gettime
00000144 g F .text 00000088 clock_gettime@@GLIBC_2.17
00000144 g F .text 00000088 clock_gettime@GLIBC_2.2
Where with a libc_hidden_def (__clock_gettime64) it shows:
00000144 g F .text 00000088 __clock_gettime
00000144 g F .text 00000088 __clock_gettime_2
00000000 g F .text 00000144 .hidden __GI___clock_gettime64
*00000000 g F .text 00000144 __clock_gettime64
00000144 g F .text 00000088 .hidden __GI___clock_gettime
00000144 g F .text 00000088 clock_gettime@@GLIBC_2.17
00000144 g F .text 00000088 clock_gettime@GLIBC_2.2
The requirement of libc_hidden_def will de defined in the end if glibc
exports or not __clock_gettime64 on some header redirection or if
clock_gettime64 would be suffice (with a {weak,strong}_alias).
However I do think we should fix it to avoid such confusion why there
is a hidden_proto and not a hidden_def.