[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230529113143.GB2762@1wt.eu>
Date: Mon, 29 May 2023 13:31:43 +0200
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <thomas@...ch.de>
Cc: Zhangjin Wu <falcon@...ylab.org>, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-riscv@...ts.infradead.org,
palmer@...belt.com, paul.walmsley@...ive.com
Subject: Re: [PATCH 00/13] tools/nolibc: riscv: Add full rv32 support
Hi Thomas,
On Mon, May 29, 2023 at 10:45:40AM +0200, Thomas Weißschuh wrote:
> <lots of implementation>
>
> > usage:
> >
> > $ gcc -o nolibc-test tools/testing/selftests/nolibc/nolibc-test.c
> > $ ./nolibc-test
> > ...
> > 35 gettimeofday_tz = 0 [OK]
> > 36 gettimeofday_tv_tz = 0 [OK]
> > 37 gettimeofday_bad1 = -1 [FAIL] (continued by sigaction/siglongjmp/sigsetjmp)
> > 38 gettimeofday_bad2 = -1 [FAIL] (continued by sigaction/siglongjmp/sigsetjmp)
> > 39 getpagesize = 0 [OK]
> > 40 ioctl_tiocinq = 0 [OK]
> > 41 ioctl_tiocinq = 0 [OK]
> > ...
> >
> > It did work as expected, but for nolibc, we still need to add sigaction/siglongjump/sigsetjmp support.
> >
> > Will send a patch based on Willy's latest branch, perhaps this may help us to
> > verify the future sigaction/siglongjump/sigsetjmp for nolibc.
> >
> > ref: https://www.ibm.com/docs/en/i/7.1?topic=ssw_ibm_i_71/apis/sigsetj.html
> > https://www.ibm.com/docs/en/zos/2.1.0?topic=functions-siglongjmp-restore-stack-environment-signal-mask
>
> This seems very complicated for fairly limited gain to be honest.
I agree as well. I'm not denying the fact that one day we may want to
support signal, longjmp and friends but I'm not convinced we want to
go through that just to make a few uncertain tests succeed.
> If we really want to keep the current testcase we could also ensure that
> the pointer does not fall into the first page, as the first page is not
> mapped under Linux:
>
> 0 <= addr < PAGE_SIZE
>
> Or instead of PAGE_SIZE just hardcode 4096, as that should be the
> minimum size and and does not require a lookup.
I would not even do that. It brings nothing to the application layer and
inflates the code. I'd rather just get rid of the EFAULT test cases that
rely on an unreliable syscall (i.e. one that may either be a real syscall
or an emulated one). The value brought by these tests is extremely low
and they were implemented only because they were easy to do. If they're
causing pain, let's just drop them.
Willy
Powered by blists - more mailing lists