From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Cc: arcml <linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH v7.1 07/13] ARC: Linux Syscall Interface
Date: Tue, 7 Jul 2020 21:07:18 +0000 [thread overview]
Message-ID: <0e3bf658-10b4-0428-02f3-f2ae01c77ddf@synopsys.com> (raw)
In-Reply-To: <8ec1c7a1-dd77-5f1f-a2a4-11d214152a0d@linaro.org>
On 7/7/20 12:24 PM, Adhemerval Zanella via Libc-alpha wrote:
>
>
> On 06/07/2020 22:25, Vineet Gupta wrote:
>> On 7/6/20 6:20 AM, Adhemerval Zanella via Libc-alpha wrote:
>>>>>> diff --git a/sysdeps/unix/sysv/linux/arc/clone.S b/sysdeps/unix/sysv/linux/arc/clone.S
>>>>
>>>>>> diff --git a/sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h b/sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h
>>>>
>>>>>> +
>>>>>> +/* Adjustments to ARC asm-generic syscall ABI (3.9 kernel) for 64-bit time_t
>>>>>> + support. */
>>>>>> +
>>>>>> +/* fstat64 and fstatat64 need to be replaced with statx. */
>>>>>> +
>>>>>> +#undef __NR_fstat64
>>>>>> +#undef __NR_fstatat64
>>>>
>>>> This is certainly needed as they are present in ARC arch-syscall.h but we need to
>>>> use statx.
>>>>
>>>>>> +/* Replace all other 32-bit time syscalls with 64-bit variants. */
>>>>>> +
>>>>>> +# undef __NR_clock_adjtime
>>>>>> +# undef __NR_clock_getres
>>>>>> +# undef __NR_futex
>>>>>> +# undef __NR_mq_timedreceive
>>>>>> +# undef __NR_mq_timedsend
>>>>>> +# undef __NR_ppoll
>>>>>> +# undef __NR_pselect6
>>>>>> +# undef __NR_recvmmsg
>>>>>> +# undef __NR_rt_sigtimedwait
>>>>>> +# undef __NR_sched_rr_get_interval
>>>>>> +# undef __NR_semtimedop
>>>>>> +# undef __NR_timerfd_settime
>>>>>> +# undef __NR_timerfd_gettime
>>>>>> +# undef __NR_utimensat
>>>>>
>>>>> I am trying to understand why these are required since arc does not define
>>>>> them in arch-syscall.h.
>>>>
>>>> arch-syscall.h doesn't define them precisely due to these being here. When
>>>> update-syscalls is run, the 32-bit syscalls are generated for ARC (since kernel
>>>> ABI provides these because that was v3.9 circa 2013). Adding them
>>>> fixup-asm-unistd.h removes them (perhaps I need to add this in changelog to
>>>> clarify - atleast for myself).
>>>>
>>>>> And the generic implementation should handle the time64 variant. If they
>>>>> are not this is something we need to handle it.
>>>>
>>>> At the time we we doing this, arch-syscall.h generation was not yet in place,
>>>> however I tried to undef in generic/sysdep.h for TIMESIZE==64. However I was asked
>>>> me to add this to ARC specific fixup-asm-unistd.h
>>>> https://sourceware.org/pipermail/libc-alpha/2020-March/112395.html
>>>> https://sourceware.org/pipermail/libc-alpha/2020-April/112909.html
>>>
>>> My confusion here, I forgot that this header is only used glibcsyscalls.py
>>> to actually generate arch-syscall.h.
>>>
>>> You changes does look correct.
>>
>> Actually we can add a few more entries here which have 64-bit variants.
>>
>> +# undef __NR_clock_gettime
>> +# undef __NR_clock_nanosleep
>> +# undef __NR_clock_settime
>> +# undef __NR_timer_gettime
>> +# undef __NR_timer_settime
>
> It should not intefere since ARC also defines __ASSUME_TIME64_SYSCALLS
> and the 32-bit fallback syscalls won't be used in this case.
In an ideal world yes, but as we see from hacks in sysdep.h, there's code which
build/works inadvertently. If nothing else, this documents that those syscalls are
not to be used.
> As a side note, now that arch-syscall.h is based on latest kernel version
> and all the 32-bit ABIs with old 32-bit time_t have upstream support for
> 64-bit time_t we can simplify a bit some implementation by assuming
> the 64-bit time_t is always defined and adding a fallback only for
> !define __ASSUME_TIME64_SYSCALLS.
OK.
>>>>>> diff --git a/sysdeps/unix/sysv/linux/arc/sysdep.h b/sysdeps/unix/sysv/linux/arc/sysdep.h
>>>>
>>>> ...
>>>>
>>>>>> +/* 32-bit time syscalls are not available, but the redefines allow generic
>>>>>> + wrappers to work. */
>>>>>> +#define __NR_clock_adjtime __NR_clock_adjtime64
>>>>>> +#define __NR_clock_getres __NR_clock_getres_time64
>>>>>> +#define __NR_futex __NR_futex_time64
>>>>>> +#define __NR_mq_timedreceive __NR_mq_timedreceive_time64
>>>>>> +#define __NR_mq_timedsend __NR_mq_timedsend_time64
>>>>>> +#define __NR_ppoll __NR_ppoll_time64
>>>>>> +#define __NR_pselect6 __NR_pselect6_time64
>>>>>> +#define __NR_recvmmsg __NR_recvmmsg_time64
>>>>>> +#define __NR_rt_sigtimedwait __NR_rt_sigtimedwait_time64
>>>>>> +#define __NR_sched_rr_get_interval __NR_sched_rr_get_interval_time64
>>>>>> +#define __NR_semtimedop __NR_semtimedop_time64
>>>>>> +#define __NR_timerfd_gettime __NR_timerfd_gettime64
>>>>>> +#define __NR_timerfd_settime __NR_timerfd_settime64
>>>>>> +#define __NR_utimensat __NR_utimensat_time64
>>>>>
>>>>> As for the fixup-asm-unistd.h, the generic implementation should handle it
>>>>> without the requirement of the ABI to add such tricks.
>>>>
>>>> fixup-asm-unistd.h is different, but this could be avoided. I know for sure that
>>>> ll code literally expects __NR_futex (atleast used to). But I can remove this and
>>>> see what comes out.
>>>>
>>>>>
>>>>> However it seems that we are still missing support for pselect
>>>>> (__NR_pselect6_time64), recvmmsg (__NR_recvmmsg_time64), sigtimedwait
>>>>> (__NR_rt_sigtimedwait_time64), and semtimeop (__NR_semtimedop_time64).
>>>>>
>>>>> I think we can add the redefine hack only the aforementioned symbols for
>>>>> now and removed them once we implement the y2038 support on such symbols
>>>>> (since the expected ABI won't change for ARC, only for old ABIs with
>>>>> 32 time_t support).
>>>>
>>>> Sorry /me horribly confused here.
>>>
>>> Sorry for the confusion, I meant that some of these re-defines are superfluous
>>> and I would like to have the minimum required re-define to enable the ARC
>>> support,
>>
>> Right. The generic code needs a bit more work to eliminate the redefines altogether.
>>
>> 1. Following is not needed
>>
>> -#define __NR_clock_adjtime __NR_clock_adjtime64
>> -#define __NR_sched_rr_get_interval __NR_sched_rr_get_interval_time64
>> -#define __NR_mq_timedreceive __NR_mq_timedreceive_time64
>> -#define __NR_mq_timedsend __NR_mq_timedsend_time64
>> -#define __NR_timerfd_gettime __NR_timerfd_gettime64
>> -#define __NR_timerfd_settime __NR_timerfd_settime64
>
> Ok.
>
>>
>> 2. The minimum list needed for ARC (with annotations as to which generic file
>> needs fixing).
>>
>> /* Fix sysdeps/unix/sysv/linux/clock_getcpuclockid.c. */
>> #define __NR_clock_getres __NR_clock_getres_time64
>
> It should be simple since there is no need to provide an extra symbol
> for old ABIs, it would be to just use __NR_clock_getres_time64 if it
> is defined.
>
>> /* Fix sysdeps/nptl/lowlevellock-futex.h. */
>> #define __NR_futex __NR_futex_time64
>
> It seems Lukasz Majewski has sent a patchset to address it (I haven't
> checked the detail yet).
>
>> /* Fix sysdeps/unix/sysv/linux/pause.c. */
>> #define __NR_ppoll __NR_ppoll_time64
>
> This is another one similar to clock_getcpuclockid.
>
>> /* Fix sysdeps/unix/sysv/linux/select.c. */
>> #define __NR_pselect6 __NR_pselect6_time64
>
> I have a patch for select [1], it a bit more complex because we need to
> handle both the timeout and the microblaze lacking support of
> pselect6.
>
>> /* Fix sysdeps/unix/sysv/linux/recvmmsg.c. */
>> #define __NR_recvmmsg __NR_recvmmsg_time64
>
> I also have a patch for this [1], although it still does not have the
> ancillary data from struct msghdr which might return SCM_TIMESTAMP
> information (which returns struct timespec). The recvmsg also has
> the same issue regarding ancillary data.
>
>> /* Fix sysdeps/unix/sysv/linux/sigtimedwait.c. */
>> #define __NR_rt_sigtimedwait __NR_rt_sigtimedwait_time64
>
> The patch for is more straighfoward [1].
>
>> /* Fix sysdeps/unix/sysv/linux/semtimedop.c. */
>> #define __NR_semtimedop __NR_semtimedop_time64
>
> The patch for is also straighfoward [1].
>
>
>> /* Hack sysdeps/unix/sysv/linux/generic/utimes.c (need linux/utimes.c). */
>> #define __NR_utimensat __NR_utimensat_time64
>
> Lukasz Majewski also has a patchset for this, I will check this out.
Thanks for tacking this.
>>> so we can cleanup these later once we enable time64_t support on
>>> old ABIs as well.
>>
>> IMO the cleanup applies to new ABIs too as generic code should handle those cases
>> w/o these workarounds. But that would delay things further for new ports so I
>> suggest we keep the workarounds and clean things up going fwd.
>
> I agree, this can be worked in parallel.
Thx for being pragmatic. Given ABI freeze we will merge ARC with workarounds and
clean them up in 2.33 ?
>> BTW, if one were to actually go about fixing those, whats the best approach.
>> Consider the simplest case pause(). For !__NR_pause do we replicate the code for
>> ppoll/ppoll64 handling or simply just call ppoll(). Later has a function call
>> overhead) ? Or there is a paradigm to use __syscallxxx_helper() although that
>> still has a function call overhead.
>>
>> Actually the pause case is really simple as there are no args, so just redefine
>> __NR_xxx trick should suffice w/o going into all the explicit
>> interworking/conversion etc.
>>
>> __libc_pause (void)
>> {
>> #ifdef __NR_pause
>> return SYSCALL_CANCEL (pause);
>> #else
>>
>> return SYSCALL_CANCEL (ppoll, NULL, 0, NULL, NULL);
>> #endif
>>
>
> Each implementation has it ows requirements so I can't really say if
> a helper function does make sense for all of them. For pause
> specifically we can even simplify to since all architectures have
> either ppoll or ppoll_time64:
>
> int
> __libc_pause (void)
> {
> #ifdef __NR_ppoll_time64
> return SYSCALL_CANCEL (ppoll_time64, NULL, 0, NULL, NULL);
> #else
> return SYSCALL_CANCEL (ppoll, NULL, 0, NULL, NULL);
> #endif
> }
But how is this compatible with older kernels (and perhaps this is a general
question). I mean one/more ABIs minimum kernel would not have the ppoll or ppoll64
so how will new glibc work with such a kernel ? Is it not required to ?
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
next prev parent reply other threads:[~2020-07-07 21:07 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 20:14 [PATCH v7 00/13] glibc port to ARC processors Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 01/13] ARC: ABI Implementation Vineet Gupta
2020-07-01 0:06 ` [PATCH v7.1 " Vineet Gupta
[not found] ` <b6322150-240a-5f06-b700-83e3eb79deec@linaro.org>
2020-07-01 19:36 ` Vineet Gupta
2020-07-01 19:45 ` Adhemerval Zanella
2020-06-15 20:14 ` [PATCH v7 02/13] ARC: startup and dynamic linking code Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 03/13] ARC: Thread Local Storage support Vineet Gupta
2020-07-01 0:07 ` [PATCH v7.1 " Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 04/13] ARC: Atomics and Locking primitives Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 05/13] ARC: math soft float support Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 06/13] ARC: hardware floating point support Vineet Gupta
2020-07-01 0:08 ` [PATCH v7.1 " Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 07/13] ARC: Linux Syscall Interface Vineet Gupta
2020-07-01 0:08 ` [PATCH v7.1 " Vineet Gupta
[not found] ` <e9e2ae28-cd78-5924-c1fa-52b1499c245a@linaro.org>
2020-07-04 3:54 ` Vineet Gupta
2020-07-06 13:20 ` Adhemerval Zanella
2020-07-07 1:25 ` Vineet Gupta
2020-07-07 19:24 ` Adhemerval Zanella
2020-07-07 20:55 ` [PATCH v7.2 " Vineet Gupta
[not found] ` <b64d0df1-4229-d619-0ab1-ded287323775@linaro.org>
2020-07-08 19:32 ` Vineet Gupta
2020-07-09 16:03 ` Adhemerval Zanella
2020-07-09 16:24 ` Vineet Gupta
2020-07-09 16:25 ` Adhemerval Zanella
2020-07-09 21:13 ` Vineet Gupta
2020-07-09 21:36 ` ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface) Vineet Gupta
2020-07-09 22:01 ` Alistair Francis
2020-07-09 22:16 ` Vineet Gupta
2020-07-10 9:28 ` Florian Weimer
2020-07-10 15:53 ` Vineet Gupta
2020-07-10 17:02 ` Florian Weimer
2020-07-10 20:07 ` Vineet Gupta
2020-07-10 20:32 ` Florian Weimer
2020-07-10 19:12 ` Alistair Francis
2020-07-10 20:33 ` Florian Weimer
2020-07-10 20:56 ` Alistair Francis
2020-07-10 19:10 ` Alistair Francis
2020-07-07 21:07 ` Vineet Gupta [this message]
2020-07-07 21:32 ` [PATCH v7.1 07/13] ARC: Linux Syscall Interface Joseph Myers
2020-07-07 23:16 ` Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 08/13] ARC: Linux ABI Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 09/13] ARC: Linux Startup and Dynamic Loading Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 10/13] ARC: ABI lists Vineet Gupta
2020-07-01 0:09 ` [PATCH v7.1 " Vineet Gupta
2020-06-15 20:14 ` [PATCH v7 11/13] ARC: Build Infrastructure Vineet Gupta
2020-07-03 17:09 ` Adhemerval Zanella
2020-06-15 20:14 ` [PATCH v7 12/13] build-many-glibcs.py: Enable ARC builds Vineet Gupta
2020-07-03 17:37 ` Adhemerval Zanella
2020-06-15 20:14 ` [PATCH v7 13/13] Documentation for ARC port Vineet Gupta
2020-07-03 17:38 ` Adhemerval Zanella
2020-06-23 16:56 ` [PATCH v7 00/13] glibc port to ARC processors Vineet Gupta
2020-07-01 0:11 ` Vineet Gupta
2020-07-01 1:44 ` Adhemerval Zanella
2020-07-01 19:13 ` Vineet Gupta
2020-07-02 1:00 ` ARC math test regressions (was Re: [PATCH v7 00/13] glibc port to ARC processors) Vineet Gupta
2020-07-02 7:17 ` Andreas Schwab
2020-07-02 16:27 ` Joseph Myers
2020-07-02 17:45 ` Vineet Gupta
2020-07-02 21:27 ` [PATCH v7 00/13] glibc port to ARC processors Joseph Myers
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e3bf658-10b4-0428-02f3-f2ae01c77ddf@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-snps-arc@lists.infradead.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 NNTP newsgroup(s).