From: Alistair Francis <alistair23@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Rich Felker <dalias@libc.org>,
Florian Weimer <fweimer@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Accelerating Y2038 glibc fixes
Date: Fri, 19 Jul 2019 12:03:46 -0700 [thread overview]
Message-ID: <CAKmqyKMc4mQh8iNNaG6PEV90iGAz_CK5Po8OvLscNQLNd5fqGw@mail.gmail.com> (raw)
In-Reply-To: <ca362f2d-0d5f-52af-43ce-138a0a320bd2@linaro.org>
On Fri, Jul 19, 2019 at 10:44 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 19/07/2019 00:06, Rich Felker wrote:
> > On Thu, Jul 18, 2019 at 05:31:51PM -0300, Adhemerval Zanella wrote:
> >>
> >>
> >> On 18/07/2019 16:13, Florian Weimer wrote:
> >>> * Adhemerval Zanella:
> >>>
> >>>> So what about to not add a user-selected way to set the time_t size
> >>>> (as off_t) and just enable time64_t support and sets is as default for
> >>>> build with a minimum kernel of v5.1 (if I recall correctly as being the
> >>>> one that added time64 support)?
> >>>
> >>> Does this mean that some developers see a glibc 2.31 with a 32-bit
> >>> time_t on i386, and others see a 64-bit time_t?
> >>>
> >>>> It will move all time32 support as compat symbols for the required ABI,
> >>>> without an option to select it through a build flag. Newer ports will
> >>>> just have the expected symbol names, no tinkering needed.
> >>>
> >>> But if we build glibc with pre-5.1 kernel headers, you will get the
> >>> legacy interface?
> >>
> >> My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION
> >> when time64 is used. So, depending on how glibc is built, developers
> >> will indeed see a different time_t.
> >>
> >> Legacy builds won't build any time64 support, even with newer kernels.
> >> Build set with --enable-kernel will automatically set time_t as time64
> >> and redirect the required interfaces to the new symbols ones (similar
> >> to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default).
> >>
> >> Newer 32-bit ports won't require anything like this as expected.
> >>
> >> I still think that in long term this initial bump transition is better
> >> than to the complexity from mixed support.
> >
> > I see no reason for it to depend on the minimum kernel version glibc
> > is built for. You should be able to build glibc that runs on the
> > oldest still-supported kernels and that uses 64-bit time_t in the
> > application-facing ABI.
> >
> > If built with --enable-kernel new enough, the fallback code to use old
> > syscalls when the time64 ones fail with ENOSYS can be omitted. If not,
> > the time64 syscalls are tried first, and if they fail, the old
> > syscalls are used and the results converted.
> >
> > This is what musl has always planned to do regardless of whether we go
> > with a hard ABI break or symbol redirection. "Only works on
> > bleeding-edge kernels" is a sure way to make sure nobody uses the new
> > thing, resulting in continued production of legacy binaries that are
> > ticking timebombs far into the future, and all the exploding popcorn
> > when 2038 approaches...
>
> I am aiming for make the required changes less complex and allow the
> distributions to have a way to actually set or not whether to support
> time64, since you can still build glibc aiming for default minimum
> (3.2) while still providing a time64 enabled kernel. I personally prefer
> to just make the switch based on release rather than a configure option.
>
> And I do agree with you that it is feasible to just make the switch
> on glibc 2.31 for all 32-bit architectures and move on. However
> we will need to take care of glibc some conventions, so instead of just
>
> --
> #if __LINUX_KERNEL_VERSION >= 0x050100
> # define __ASSUME_TIME64_SYSCALLS 1
> #endif
>
> int
> syscall_name (...)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
> return INLINE_SYSCALL_CALL (syscall64, ...);
> #else
> return INLINE_SYSCALL_CALL (syscall, ...);
> #endif
> }
> ---
>
> We will need to have something like:
>
> --
> #if __LINUX_KERNEL_VERSION >= 0x050100 >= 0x050100
> # define __ASSUME_TIME64_SYSCALLS 1
> #endif
>
> int
> syscall_name (args...)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
> return INLINE_SYSCALL_CALL (syscall64, args...);
> #else
> int ret;
> # ifdef __NR_syscall64
> static int syscall_name_supported = 1;
> if (atomic_read_relaxed (&syscall_name_supported) == 1)
> {
> ret = INLINE_SYSCALL_CALL (syscall64, args...);
> if (ret == 0 || errno != ENOSYS)
> return ret;
>
> atomic_store_relaxed (&syscall_name_supported, 0)
> }
> # endif /* __NR_syscall64 */
>
> ret = INLINE_SYSCALL_CALL (syscall, args...);
> if (ret == 0)
> ret = convert_syscall_time_to_time64 (args, ...);
> return ret;
> #endif
> }
> --
Great! This was my understanding as well (although not every patch in
the latest RV32 RFC does this, that is an oversight).
>
> For the syscall implementation. We will have some more complexity to handle
> vDSO, but it should be simplified with my refactor.
Also good news!
Alistair
next prev parent reply other threads:[~2019-07-19 19:07 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 7:21 Accelerating Y2038 glibc fixes Wolfgang Denk
2019-07-16 9:32 ` Wolfgang Denk
2019-07-16 11:50 ` Siddhesh Poyarekar
2019-07-16 12:40 ` Wolfgang Denk
2019-07-16 12:44 ` Florian Weimer
2019-07-16 14:52 ` Wolfgang Denk
2019-07-16 15:09 ` Florian Weimer
2019-07-16 15:19 ` Andrew Pinski
2019-07-17 14:15 ` Arnd Bergmann
2019-07-17 14:41 ` Florian Weimer
2019-07-17 16:00 ` Wolfgang Denk
2019-07-17 16:04 ` Florian Weimer
2019-07-17 16:18 ` Lukasz Majewski
2019-07-18 18:53 ` Adhemerval Zanella
2019-07-18 19:13 ` Florian Weimer
2019-07-18 20:31 ` Adhemerval Zanella
2019-07-18 21:20 ` Florian Weimer
2019-07-18 22:32 ` Paul Eggert
2019-07-19 7:21 ` Andreas Schwab
2019-07-19 3:06 ` Rich Felker
2019-07-19 17:44 ` Adhemerval Zanella
2019-07-19 19:03 ` Alistair Francis [this message]
2019-07-25 20:40 ` Joseph Myers
2019-07-29 17:47 ` Adhemerval Zanella
2019-07-29 19:58 ` Joseph Myers
2019-07-29 21:00 ` Adhemerval Zanella
2019-07-29 21:08 ` Joseph Myers
2019-07-29 23:12 ` Paul Eggert
2019-07-29 23:30 ` Joseph Myers
2019-07-17 17:50 ` Rich Felker
2019-07-17 21:57 ` Lukasz Majewski
2019-07-17 22:37 ` Rich Felker
2019-07-18 7:20 ` Lukasz Majewski
2019-07-18 13:35 ` Rich Felker
2019-07-18 14:47 ` Rich Felker
2019-07-18 14:49 ` Florian Weimer
2019-07-18 15:46 ` Rich Felker
2019-07-18 16:43 ` Adhemerval Zanella
2019-07-20 4:43 ` Rich Felker
2019-07-25 19:54 ` Joseph Myers
2019-07-26 10:39 ` Lukasz Majewski
2019-07-29 18:55 ` Zack Weinberg
2019-07-29 20:12 ` Joseph Myers
2019-07-30 11:02 ` Lukasz Majewski
2019-07-30 12:24 ` Joseph Myers
2019-07-30 14:04 ` Lukasz Majewski
2019-08-09 7:25 ` Lukasz Majewski
[not found] ` <CAKCAbMhOMQ9yTFpy+OQkDvZPPFf_fFn6oSxjvLTaUwC4jpPRag@mail.gmail.com>
2019-08-09 12:32 ` Fwd: " Zack Weinberg
2019-07-30 19:58 ` Joseph Myers
2019-07-30 20:28 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKmqyKMc4mQh8iNNaG6PEV90iGAz_CK5Po8OvLscNQLNd5fqGw@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=dalias@libc.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).