Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp4725976rwd; Tue, 23 May 2023 11:31:30 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7kfD1nPg08JE0DsK1FERtMQD2FT9TFAZNYFTZKu6/0qW9R0mMJoq4mEDapykIez3u5mr2O X-Received: by 2002:a05:6a20:8f26:b0:10b:c341:935 with SMTP id b38-20020a056a208f2600b0010bc3410935mr7102958pzk.11.1684866690145; Tue, 23 May 2023 11:31:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684866690; cv=none; d=google.com; s=arc-20160816; b=zMfktSwjl+XlDiTGPf1wvY5WnygZOk1RkE7cPKoldm2puFwWqUV+7j3nN1wzinqukZ K1BE734AxdQLUxZqJZEXGF2tM0XROeOUIxTeU/EK5TvyWuodMVI8lNoSTqyiiLe0paSj f3/Urmmc2oka7yeRe8MzvO+wNav171b7Mc7+NW+AMcdCrlSqTat6PUYyIMLLh3FTrhZe TmU+2cjT9uqxg3TBrn4Tqsg8j9jJ23lIn09y54zTaz/hgU+l5sFUpnox+z76MXRK8X6I gbvvEt8aNQng7MROLhr3uM4jgs6NcFgK0VY9tjCVozRL9yk/5Veva34lcqAtM2ibEyVp kyFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:feedback-id:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from; bh=LfhxFG1Z+a3pmBb46mTfls7N9W2lhXhIIvriVuK0Xtg=; b=m1rM3SWePA5ZGQD2ROaVKs13E4hiaEULHCqYLERnYVXxHlo8FgeyPvZbhKrZc933Sw idMXVNTFc+nxtsbpoqnVCPuu50ujcpgBjKuePLtN85XDE8c3s27iqCA+vEidq+cr7Pq5 q2PjZx3m854JpJE4pRSPLIXLSejSIKzjROYmfD45leqDgvT3arzpPZPTHMRrIF4T6Hhr SKMif05yYF6sFwDIyrArR6rnv8BbuW+tEflTnyo2SnpCvVTetR5LcAfOYf9LO+4HZV1A woGP9VTGOq3BNV7Riesa7P5lzl9Y8aYzZU9wPDXGzCLZnip6sJ5Zq4BobiGwF4divULb 4JLQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l19-20020a639853000000b0053063a32dacsi4718200pgo.826.2023.05.23.11.31.15; Tue, 23 May 2023 11:31:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238111AbjEWSEF (ORCPT + 99 others); Tue, 23 May 2023 14:04:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238028AbjEWSEC (ORCPT ); Tue, 23 May 2023 14:04:02 -0400 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.155.67.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2194AC2; Tue, 23 May 2023 11:03:58 -0700 (PDT) X-QQ-mid: bizesmtp71t1684865022tcxah01h Received: from linux-lab-host.localdomain ( [116.30.125.36]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 24 May 2023 02:03:41 +0800 (CST) X-QQ-SSF: 01200000000000D0V000B00A0000000 X-QQ-FEAT: swyrzWPvyR0MduXpVglWqnX/F5HbgaaQRtAemZVP+sG0/GJZ2D1Y/ShFZ8m7+ ziR3C6JHZMUzvcAn2FwvU648OVTDIxR4ZJYfKygUbbeMPfvz3ccq3CKNE64aCcEq9+CCn0q CiFhW82vl2CW0rnJ89xQJLaOf4AnSnB1nFzruLcHLazA5iZHRefcLmVGCSnfLohCMb14uh8 Dqy6oCARHkBhf58RZyuHqP6VQj6FGIG91XExRJffbaM0xxWFA/56fJYzS6hgl9URmJQjHup 1/AB5I3hQEDTSVrksGlevBahKLR8aiEtXT6GhGb816t/Pepo2YvLvONJFiXjl7YaO6A3oX1 n5T+gFHCX3N7qPbIcZCvkprKTpJHw== X-QQ-GoodBg: 0 X-BIZMAIL-ID: 17320655173653481143 From: Zhangjin Wu To: thomas@t-8ch.de, w@1wt.eu Cc: falcon@tinylab.org, aou@eecs.berkeley.edu, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org, palmer@dabbelt.com, paul.walmsley@sifive.com, shuah@kernel.org Subject: Re: [PATCH] selftests/nolibc: Fix up compile error for rv32 Date: Wed, 24 May 2023 02:03:40 +0800 Message-Id: <20230523180340.466619-1-falcon@tinylab.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230521180823.164289-1-falcon@tinylab.org> References: <20230521180823.164289-1-falcon@tinylab.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrsz:qybglogicsvrsz3a-3 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Willy, Thomas Good news, I just fixed up all of the time32 syscalls related build and test failures for rv32 and plan to send out the whole patchset tomorrow. The patchset is based on 20230520-nolibc-rv32+stkp2 of [1] and the new statckprotect patchset [2] (If v2 is ready, I prefer to rebase on v2). [1]: https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git [2]: https://lore.kernel.org/linux-riscv/20230521100818.GA29408@1wt.eu/T/#t For the fstat compile issue, I prefer to use a __NR_statx for rv32 instead of using fstatfs, because of different fstatfs* have different errno's, it is ugly to use lots of macros ;-) what's your suggestion? Here is the __NR_statx version: +static int test_syscall_args(void) +{ +#ifdef __NR_statx + return syscall(__NR_statx, 0, NULL, 0, 0, NULL); +#elif defined(__NR_fstat) + return syscall(__NR_fstat, 0, NULL); +#else +#error Neither __NR_statx nor __NR_fstat defined, cannot implement syscall_args test +#endif +} And the fstatfs version: +#ifdef __NR_fstatfs64 +#define EXPECT_SYSER_SYSCALL_ARGS() EXPECT_SYSER(1, syscall(__NR_fstatfs64, 0, 0, NULL), -1, EINVAL) +#elif defined(__NR_fstatfs) +#define EXPECT_SYSER_SYSCALL_ARGS() EXPECT_SYSER(1, syscall(__NR_fstatfs, 0, NULL), -1, EFAULT) +#elif defined(__NR_fstat) +#define EXPECT_SYSER_SYSCALL_ARGS() EXPECT_SYSER(1, syscall(__NR_fstat, 0, NULL), -1, EFAULT) +#else +#error None of __NR_fstatfs64, __NR_fstatfs and __NR_fstat defined, cannot implement syscall_args test +#endif And I plan to move __NR_fstat as the first branch to make sure it works as before on the other platforms. > 30 fork = 1 ENOSYS [FAIL] > 33 gettimeofday_null = -1 ENOSYS [FAIL] > 35 gettimeofday_bad1 = -1 ENOSYS != (-1 EFAULT) [FAIL] > 36 gettimeofday_bad2 = -1 ENOSYS != (-1 EFAULT) [FAIL] > 37 gettimeofday_bad2 = -1 ENOSYS != (-1 EFAULT) [FAIL] > 51 poll_null = -1 ENOSYS [FAIL] > 52 poll_stdout = -1 ENOSYS [FAIL] > 53 poll_fault = -1 ENOSYS != (-1 EFAULT) [FAIL] > 56 select_null = -1 ENOSYS [FAIL] > 57 select_stdout = -1 ENOSYS [FAIL] > 58 select_fault = -1 ENOSYS != (-1 EFAULT) [FAIL] > 64 wait_child = -1 ENOSYS != (-1 ECHILD) [FAIL] > 65 waitpid_min = -1 ENOSYS != (-1 ESRCH) [FAIL] > 66 waitpid_child = -1 ENOSYS != (-1 ECHILD) [FAIL] > All of the above failures have been fixed up, some of them are very easy, some of them are a little hard. 1. 30, 64-66 depends on wait4, use waitid instead 2. 33-37 depends on gettimeofday, use clock_gettime64 instead 3. 51-53 depends on ppoll, use ppoll_time64 instead 4. 56-58 depends on pselect*, use pselect_time64 instead And I have found there are two same 'gettimeofday_bad2', is it designed? If no, I will send a patch to dedup it: CASE_TEST(gettimeofday_bad2); EXPECT_SYSER(1, gettimeofday(NULL, (void *)1), -1, EFAULT); break; CASE_TEST(gettimeofday_bad2); EXPECT_SYSER(1, gettimeofday(NULL, (void *)1), -1, EFAULT); break; > > My suggestion is directly fix up the failures one by one in current stage, > because nolibc currently only uses part of the time32 syscalls, it may be not > that complex to fix up them. Have read the code of musl and glibc today, both > of them have good time64 syscalls support, I plan to fix up the above failures > in several days, hope so but no promise ;-) > both musl and glibc help a lot, but also encounter some critical issues, for example, to pass some test cases, it is required to emulate the same path of the target syscalls and return the same errno's for them, the code comment will exaplain the details. > And another question: for the new changes, If a platform support both of the > 32bit and 64bit syscalls, do we need to put the 64bit syscalls at first? > To make sure not touch too much on the code and reduce test cost, the patchset just kept the default code order and let the old code in the first branch. I plan to send the whole patchset tomorrow. Thanks, Zhangjin