Message ID | 20231012-nolibc-linkage-test-v1-1-315e682768b4@weissschuh.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp870977vqb; Wed, 11 Oct 2023 16:14:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFNRfqCxKlb3rYmAZXf0vhr3vIENhZaAK5suaJ6M1dIvIGFDY6AwUB7B38rFNFFhp7vfsyH X-Received: by 2002:a17:90b:1496:b0:27c:f88f:11a5 with SMTP id js22-20020a17090b149600b0027cf88f11a5mr4863269pjb.2.1697066055775; Wed, 11 Oct 2023 16:14:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697066055; cv=none; d=google.com; s=arc-20160816; b=CU7aoPGG9A6ndECtXTXcgtDVDN4LbkamiJ2e1Gnp5qTZjiKWY0XirMBsyV5LYDLCPx CcG6elCMM6sn7azCHXkLEkBb9CakcN1ZK+NpN8D5h22PJz3eEQ/xtC+bdUbxHW56Sgm3 ULFKR4Zbed+ZBxmtxsGBSrNHLbFcE+CRCr1Of9tw7WT5+vXic7Upgkou99zTPCqH22ho BFbGpZ6X3oe48B7/qcO4gN7fDEUKgUftlB5GMB+5z/PwunzI//V1dPyYBh3DPI4imvzV 1H9Tgc3/U76k8YPXUjWcaoLLxcDwPMZehzAATMkBfH84A11+CRF0eqoBUDRupkTJO3nJ J6Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=gGNCEVhv/eYtdUCNC6Jotp0eY9F4+uT+oxe2uX7/UQE=; fh=EDKIcR66WxqPlZsIuGZcKFboMucCJ6Mk8jlEqkSbLMM=; b=0zoZv+7JPKlnb1M3psaNpj3y+S7JchRlN+C/jlkicWA1ZTAdZfKh4QuGk1qRojnLZi GcYcHM6SnJqEwXylaNgq5B01BDiTOKF3pv98MnVWvprcwxgnpgqArbQVltK8bIy8Q3uX RRC/N5c1ZD6C3VXsZuoQd7LURHDrs14Cd1/HqcAETsR7+1fJjGSG6Z98Cv1Ksn6+YwX+ 3H9/5otZLvaiHQrea2i4GDaO1ooWvwrpEJ1XJtx2sMMu1VwL7qjq/Ug/K856SaOEMghT 1OliQgGTK1lid13kzOL5mubGiQpVTA5PCT4QJWPl8puMnwjpOkLyToWZCEy51ajZwneL qW1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=MULKEnwl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id j20-20020a17090aeb1400b002777ccd05bcsi827399pjz.25.2023.10.11.16.14.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 16:14:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=MULKEnwl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 67A4980E0A53; Wed, 11 Oct 2023 16:14:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235217AbjJKXN6 (ORCPT <rfc822;kartikey406@gmail.com> + 18 others); Wed, 11 Oct 2023 19:13:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233834AbjJKXNw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 11 Oct 2023 19:13:52 -0400 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 264A6AF for <linux-kernel@vger.kernel.org>; Wed, 11 Oct 2023 16:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1697066029; bh=3Asz/9K6lSQ6yuDvssERdpNPh6T7AlEfx+cPmP4YpDg=; h=From:Date:Subject:To:Cc:From; b=MULKEnwlv15MaNKqkDGlRLb49Xpw6Mbr8k3+vMD3CNxmmKokwGbSkcV8TqKIBNAmq JgaFdXivAt2mqG58YiUfsf7qBbLGZaVXcOuYJ4/0eq3hH9+G9JNBt9TkhEvNQ6LQpW atqHzG625nnVLXocrFm+FV3KsAI+DSceBWrSLmTI= From: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> Date: Thu, 12 Oct 2023 01:13:37 +0200 Subject: [PATCH] selftests/nolibc: add tests for multi-object linkage MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20231012-nolibc-linkage-test-v1-1-315e682768b4@weissschuh.net> X-B4-Tracking: v=1; b=H4sIACAsJ2UC/x2MTQqAIBQGrxJvneBPRHSVaJH2VY/CQiMC8e5Jy 2GYSRQRGJH6KlHAw5FPX0DVFblt8isEz4VJS22UVFr482DrxMF+n4q9EW/RdLBodWsWWCrlFbD w+1+HMecPUqCcuGUAAAA= To: Willy Tarreau <w@1wt.eu> Cc: Zhangjin Wu <falcon@tinylab.org>, linux-kernel@vger.kernel.org, =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1697066028; l=4748; i=linux@weissschuh.net; s=20221212; h=from:subject:message-id; bh=3Asz/9K6lSQ6yuDvssERdpNPh6T7AlEfx+cPmP4YpDg=; b=EkUqZysYQqZ1VQVIDDAqlColxK3SI2GI84lPgdHwc/SngVc1Ld2I4BBpjCC6x+jpdeLFBy6Qc hPofArPJkCLAtGi81kaLmbykG5QIlM3arSPiRBfpmlCxloaPya+OK1u X-Developer-Key: i=linux@weissschuh.net; a=ed25519; pk=KcycQgFPX2wGR5azS7RhpBqedglOZVgRPfdFSPB1LNw= X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 11 Oct 2023 16:14:13 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779502736592740377 X-GMAIL-MSGID: 1779502736592740377 |
Series |
selftests/nolibc: add tests for multi-object linkage
|
|
Commit Message
Thomas Weißschuh
Oct. 11, 2023, 11:13 p.m. UTC
While uncommon, nolibc executables can be linked together from multiple
compilation units.
Add some tests to make sure everything works in that case.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Note:
This depends on path "tools/nolibc: mark start_c as weak".
https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
---
tools/testing/selftests/nolibc/Makefile | 12 ++++-----
.../testing/selftests/nolibc/nolibc-test-linkage.c | 30 ++++++++++++++++++++++
.../testing/selftests/nolibc/nolibc-test-linkage.h | 9 +++++++
tools/testing/selftests/nolibc/nolibc-test.c | 4 +++
4 files changed, 49 insertions(+), 6 deletions(-)
---
base-commit: e76716696ba0c5c41667a11caa092cd619a79c5b
change-id: 20231012-nolibc-linkage-test-48ebe6263feb
Best regards,
Comments
Hi Thomas, On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote: > While uncommon, nolibc executables can be linked together from multiple > compilation units. > Add some tests to make sure everything works in that case. (...) Glad you did these two. Your approach is good and it remains easy to use and should catch next breakage in this area. > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > --- > Note: > > This depends on path "tools/nolibc: mark start_c as weak". > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/ For these two patches: Acked-by: Willy Tarreau <w@1wt.eu> Thanks Willy
Hi Willy, Paul, On 2023-10-12 09:06:33+0200, Willy Tarreau wrote: > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote: > > While uncommon, nolibc executables can be linked together from multiple > > compilation units. > > Add some tests to make sure everything works in that case. > (...) [..] > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > --- > > Note: > > > > This depends on path "tools/nolibc: mark start_c as weak". > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/ > > For these two patches: Acked-by: Willy Tarreau <w@1wt.eu> Thanks, applied locally. I guess the linked patch "tools/nolibc: mark start_c as weak" should also go into nolibc/fixes. @Paul, would it introduce too much churn for you if I submit another nolibc pull with an updated nolibc/fixes? (And the rebased nolibc/next with this commit while we are at it) Thomas
On Thu, Oct 12, 2023 at 09:23:29AM +0200, Thomas Weißschuh wrote: > Hi Willy, Paul, > > On 2023-10-12 09:06:33+0200, Willy Tarreau wrote: > > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote: > > > While uncommon, nolibc executables can be linked together from multiple > > > compilation units. > > > Add some tests to make sure everything works in that case. > > (...) > > [..] > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > --- > > > Note: > > > > > > This depends on path "tools/nolibc: mark start_c as weak". > > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/ > > > > For these two patches: Acked-by: Willy Tarreau <w@1wt.eu> > > Thanks, applied locally. > > I guess the linked patch "tools/nolibc: mark start_c as weak" should > also go into nolibc/fixes. > > @Paul, would it introduce too much churn for you if I submit another > nolibc pull with an updated nolibc/fixes? > (And the rebased nolibc/next with this commit while we are at it) Not a problem this week! But after about Wednesday of next week, getting things into the upcoming merge window is pretty much as fast as sending them quickly to Linus, if that makes sense. Unless there is to be a -rc8 this time, but I have heard no sign of that. Make sense? Thanx, Paul
On 2023-10-12 03:41:50-0700, Paul E. McKenney wrote: > On Thu, Oct 12, 2023 at 09:23:29AM +0200, Thomas Weißschuh wrote: > > Hi Willy, Paul, > > > > On 2023-10-12 09:06:33+0200, Willy Tarreau wrote: > > > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote: > > > > While uncommon, nolibc executables can be linked together from multiple > > > > compilation units. > > > > Add some tests to make sure everything works in that case. > > > (...) > > > > [..] > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > > --- > > > > Note: > > > > > > > > This depends on path "tools/nolibc: mark start_c as weak". > > > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/ > > > > > > For these two patches: Acked-by: Willy Tarreau <w@1wt.eu> > > > > Thanks, applied locally. > > > > I guess the linked patch "tools/nolibc: mark start_c as weak" should > > also go into nolibc/fixes. > > > > @Paul, would it introduce too much churn for you if I submit another > > nolibc pull with an updated nolibc/fixes? > > (And the rebased nolibc/next with this commit while we are at it) > > Not a problem this week! Great, then: Please pull the changes since the v6.6-rc1 tag from https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/ The branch 'fixes' up to and including 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle. The branch 'next' up to and including f2c7923763dae51226584494722349fef4df3748 for linux-next. The branch 'next', based upon 'fixes', was tested as follows: i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > But after about Wednesday of next week, getting things into the upcoming > merge window is pretty much as fast as sending them quickly to Linus, > if that makes sense. Unless there is to be a -rc8 this time, but I > have heard no sign of that. > > Make sense? Sure, hopefully no more fixes are needed! Thanks, Thomas
On Thu, Oct 12, 2023 at 12:51:28PM +0200, Thomas Weißschuh wrote: > On 2023-10-12 03:41:50-0700, Paul E. McKenney wrote: > > On Thu, Oct 12, 2023 at 09:23:29AM +0200, Thomas Weißschuh wrote: > > > Hi Willy, Paul, > > > > > > On 2023-10-12 09:06:33+0200, Willy Tarreau wrote: > > > > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote: > > > > > While uncommon, nolibc executables can be linked together from multiple > > > > > compilation units. > > > > > Add some tests to make sure everything works in that case. > > > > (...) > > > > > > [..] > > > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > > > --- > > > > > Note: > > > > > > > > > > This depends on path "tools/nolibc: mark start_c as weak". > > > > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/ > > > > > > > > For these two patches: Acked-by: Willy Tarreau <w@1wt.eu> > > > > > > Thanks, applied locally. > > > > > > I guess the linked patch "tools/nolibc: mark start_c as weak" should > > > also go into nolibc/fixes. > > > > > > @Paul, would it introduce too much churn for you if I submit another > > > nolibc pull with an updated nolibc/fixes? > > > (And the rebased nolibc/next with this commit while we are at it) > > > > Not a problem this week! > > Great, then: > > Please pull the changes since the v6.6-rc1 tag from > https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/ > > The branch 'fixes' up to and including > 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle. > > The branch 'next' up to and including > f2c7923763dae51226584494722349fef4df3748 for linux-next. > > The branch 'next', based upon 'fixes', was tested as follows: > > i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so please check the lead-in text for sanity. (Everything after the digital signature is automatically generated.) Testing for urgent/nolibc.2023.10.12a: make run: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success make run-user: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning Testing for full nolibc stack: make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success make run-user: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning > > But after about Wednesday of next week, getting things into the upcoming > > merge window is pretty much as fast as sending them quickly to Linus, > > if that makes sense. Unless there is to be a -rc8 this time, but I > > have heard no sign of that. > > > > Make sense? > > Sure, hopefully no more fixes are needed! Ah, and have these been posted to a public mailing list? If not, then I need to send them out. We reset the -next testing clock, so if all goes well, then I send the three urgent commits to Linus on Monday. Thanx, Paul
On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > [..] > > Please pull the changes since the v6.6-rc1 tag from > > https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/ > > > > The branch 'fixes' up to and including > > 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle. > > > > The branch 'next' up to and including > > f2c7923763dae51226584494722349fef4df3748 for linux-next. > > > > The branch 'next', based upon 'fixes', was tested as follows: > > > > i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > > ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > > loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > please check the lead-in text for sanity. (Everything after the digital > signature is automatically generated.) Looks good. But it's only a listing of the commit subjects, correct? > Testing for urgent/nolibc.2023.10.12a: > make run: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success > make run-user: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning > > Testing for full nolibc stack: > make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > make run-user: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning > > > > But after about Wednesday of next week, getting things into the upcoming > > > merge window is pretty much as fast as sending them quickly to Linus, > > > if that makes sense. Unless there is to be a -rc8 this time, but I > > > have heard no sign of that. > > > > > > Make sense? > > > > Sure, hopefully no more fixes are needed! > > Ah, and have these been posted to a public mailing list? If not, then I > need to send them out. All patches went through the lists as part of the normal developent flow. They were not posted after rebasing. For transparency I did the following follow-up changes: * The rebase of "tools/nolibc: mark start_c as weak" required some minor changes to resolve conflicts. * reword the message of "tools/nolibc: drop test for getauxval(AT_PAGESZ)" slightly. * simplify the includes intruduced by "selftests/nolibc: add tests for multi-object linkage". > We reset the -next testing clock, so if all goes well, then I send the > three urgent commits to Linus on Monday. Sounds good, thanks! Thomas
On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote: > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > > [..] > > > > Please pull the changes since the v6.6-rc1 tag from > > > https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/ > > > > > > The branch 'fixes' up to and including > > > 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle. > > > > > > The branch 'next' up to and including > > > f2c7923763dae51226584494722349fef4df3748 for linux-next. > > > > > > The branch 'next', based upon 'fixes', was tested as follows: > > > > > > i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > > > ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > > s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > > > loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > > please check the lead-in text for sanity. (Everything after the digital > > signature is automatically generated.) > > Looks good. But it's only a listing of the commit subjects, correct? Pretty close, just a few added words on the last one. So the question is whether there is some larger issue that Linus should be made aware of. If these are just simple fixes for simple bugs, we should be good, but yes, I do need to ask. ;-) > > Testing for urgent/nolibc.2023.10.12a: > > make run: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success > > make run-user: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning > > > > Testing for full nolibc stack: > > make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > > make run-user: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning > > > > > > But after about Wednesday of next week, getting things into the upcoming > > > > merge window is pretty much as fast as sending them quickly to Linus, > > > > if that makes sense. Unless there is to be a -rc8 this time, but I > > > > have heard no sign of that. > > > > > > > > Make sense? > > > > > > Sure, hopefully no more fixes are needed! > > > > Ah, and have these been posted to a public mailing list? If not, then I > > need to send them out. > > All patches went through the lists as part of the normal developent > flow. They were not posted after rebasing. I have been sending the group, so I might as well continue the tradition. There are a couple of substantive checkpatch complaints: 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start") The Fixes SHA-1 should be limited to 12 hex digits. (I am ignoring this, but be prepared for Linus to gripe. If you decide to fix it, I would be happy to repull.) f2c7923763da ("selftests/nolibc: add tests for multi-object linkage") nolibc-test-linkage.c and nolibc-test-linkage.h need "//" comment for the SPDX comment header. This one needs to be fixed, but this is not in the urgent stack, so there is some time. > For transparency I did the following follow-up changes: > > * The rebase of "tools/nolibc: mark start_c as weak" required some > minor changes to resolve conflicts. > * reword the message of > "tools/nolibc: drop test for getauxval(AT_PAGESZ)" slightly. > * simplify the includes intruduced by > "selftests/nolibc: add tests for multi-object linkage". Sounds good! Thanx, Paul > > We reset the -next testing clock, so if all goes well, then I send the > > three urgent commits to Linus on Monday. > > Sounds good, thanks! > > Thomas
On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote: > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote: > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > > > [..] > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > > > please check the lead-in text for sanity. (Everything after the digital > > > signature is automatically generated.) > > > > Looks good. But it's only a listing of the commit subjects, correct? > > Pretty close, just a few added words on the last one. > > So the question is whether there is some larger issue that Linus should > be made aware of. If these are just simple fixes for simple bugs, > we should be good, but yes, I do need to ask. ;-) These are simple fixes for simple bugs. Do you always have to ask specifically or can I just mention it in the pull request in the future? > [..] > > > Ah, and have these been posted to a public mailing list? If not, then I > > > need to send them out. > > > > All patches went through the lists as part of the normal developent > > flow. They were not posted after rebasing. > > I have been sending the group, so I might as well continue the tradition. Sounds good. If you want me to do something different, please let me know. > There are a couple of substantive checkpatch complaints: > > 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start") > The Fixes SHA-1 should be limited to 12 hex digits. > (I am ignoring this, but be prepared for Linus to gripe. > If you decide to fix it, I would be happy to repull.) Done. > f2c7923763da ("selftests/nolibc: add tests for multi-object linkage") > nolibc-test-linkage.c and nolibc-test-linkage.h need > "//" comment for the SPDX comment header. This one needs > to be fixed, but this is not in the urgent stack, so there > is some time. nolibc limits itself intentionally to C89 language level which disallows C++ style headers. This should be covered by Documentation/process/license-rules.rst: If a specific tool cannot handle the standard comment style, then the appropriate comment mechanism which the tool accepts shall be used. With that said: Please pull the changes since the v6.6-rc1 tag from https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/ The branch 'fixes' up to and including 921992229b1f06df6b649860e4a5f3def1489866 for the v6.6 cycle. The branch 'next' up to and including b8c60e8fc6f755c2cdf7164931afdbfa670c6646 for linux-next. No full test has been performed as only a commit message was changed. Testing for full nolibc stack: make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success make run-nolibc-test: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning Thomas
On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Weißschuh wrote: > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote: > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote: > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > > > > [..] > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > > > > please check the lead-in text for sanity. (Everything after the digital > > > > signature is automatically generated.) > > > > > > Looks good. But it's only a listing of the commit subjects, correct? > > > > Pretty close, just a few added words on the last one. > > > > So the question is whether there is some larger issue that Linus should > > be made aware of. If these are just simple fixes for simple bugs, > > we should be good, but yes, I do need to ask. ;-) > > These are simple fixes for simple bugs. > > Do you always have to ask specifically or can I just mention it in the > pull request in the future? I would be extremely happy to simply copy text from the pull request into the signed tags. ;-) We would just need to agree on the format. For example, in this case, there will eventually be two signed tags, one for the urgent pull request early next week and another for the pull request for the upcoming merge window. Proposals for the format? > > [..] > > > > > Ah, and have these been posted to a public mailing list? If not, then I > > > > need to send them out. > > > > > > All patches went through the lists as part of the normal developent > > > flow. They were not posted after rebasing. > > > > I have been sending the group, so I might as well continue the tradition. > > Sounds good. If you want me to do something different, please let me > know. > > > There are a couple of substantive checkpatch complaints: > > > > 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start") > > The Fixes SHA-1 should be limited to 12 hex digits. > > (I am ignoring this, but be prepared for Linus to gripe. > > If you decide to fix it, I would be happy to repull.) > > Done. Very good, thank you! > > f2c7923763da ("selftests/nolibc: add tests for multi-object linkage") > > nolibc-test-linkage.c and nolibc-test-linkage.h need > > "//" comment for the SPDX comment header. This one needs > > to be fixed, but this is not in the urgent stack, so there > > is some time. > > nolibc limits itself intentionally to C89 language level which disallows > C++ style headers. > > This should be covered by Documentation/process/license-rules.rst: > > If a specific tool cannot handle the standard comment style, then the > appropriate comment mechanism which the tool accepts shall be used. I stand corrected, and thank you! > With that said: > > Please pull the changes since the v6.6-rc1 tag from > https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/ > > The branch 'fixes' up to and including > 921992229b1f06df6b649860e4a5f3def1489866 for the v6.6 cycle. > > The branch 'next' up to and including > b8c60e8fc6f755c2cdf7164931afdbfa670c6646 for linux-next. > > No full test has been performed as only a commit message was changed. > > Testing for full nolibc stack: > make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success > make run-nolibc-test: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning I will pull this in, thank you! Thanx, Paul
On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote: > On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Weißschuh wrote: > > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote: > > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote: > > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > > > > > [..] > > > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > > > > > please check the lead-in text for sanity. (Everything after the digital > > > > > signature is automatically generated.) > > > > > > > > Looks good. But it's only a listing of the commit subjects, correct? > > > > > > Pretty close, just a few added words on the last one. > > > > > > So the question is whether there is some larger issue that Linus should > > > be made aware of. If these are just simple fixes for simple bugs, > > > we should be good, but yes, I do need to ask. ;-) > > > > These are simple fixes for simple bugs. > > > > Do you always have to ask specifically or can I just mention it in the > > pull request in the future? > > I would be extremely happy to simply copy text from the pull request > into the signed tags. ;-) > > We would just need to agree on the format. For example, in this case, > there will eventually be two signed tags, one for the urgent pull > request early next week and another for the pull request for the upcoming > merge window. > > Proposals for the format? Actually, proposals for the signed-tag text for the urgent commits? Left to myself, I would use the same text shown below that I proposed last week. Thanx, Paul ------------------------------------------------------------------------ tag urgent/nolibc.2023.10.12a Tagger: Paul E. McKenney <paulmck@kernel.org> Date: Thu Oct 12 10:50:08 2023 -0700 Urgent pull request for nolibc into v6.6 This pull request contains the following fixes: o tools/nolibc: i386: Fix a stack misalign bug on _start o MAINTAINERS: nolibc: update tree location o tools/nolibc: mark start_c as weak to avoid linker errors MAINTAINERS | 2 +- tools/include/nolibc/arch-i386.h | 4 +++- tools/include/nolibc/crt.h | 1 + 3 files changed, 5 insertions(+), 2 deletions(-) -----BEGIN PGP SIGNATURE----- iQJHBAABCgAxFiEEbK7UrM+RBIrCoViJnr8S83LZ+4wFAmUoMqATHHBhdWxtY2tA a2VybmVsLm9yZwAKCRCevxLzctn7jAE9D/9aa/OzGPI9VFKcN1gIW8dYJnXvSI3n +gUMjRhlWnx2DBxBkpg7jmiPUXySlsOzHoo9sgtMuOVXhkdmODZ5RL7drKJXNqxs xmpb70mftOtj/+qx3CEj71K45t5pkwidRTwOuwcNGOGM4xb6sw7kVCWinsKGSPjh l8pcJxquY2ZcKKp1OciT37IYw6AcWUz4v/JCeKLOg9FFlxIrenR56u41f7OR0GM/ D1kggSHuwAk+b0BmnUXEig2Ys0bORZ1sRQnTHjQEmba4kr41DzarwdIXMU2LUS3m dIxTtSs8kRSRZ21A9rGNEnezwZaYVdRraH3LQcDYQ4lsaccZc7xUICzHwj/DVri1 PkHVrZzii/PZGIADLYEn1ob9PjbuPXbpf6p1xZsnOCaKv1n4DcG2fHsIsCTptHkr qT8+DDu2x74WiD+lAaEuOJV1UeCDjQrTyrK2Impvg1af/d0xS6hUvDeap09OhLpW odLgtpO5xRLsWFrKl/FGCZIsLXUkvpn3F2FfU3nLgFWMFiuw6Nkk+hLlr34WqTGs A+LRYktd8moFPJRzUhgOr1jZpy8SUhs3MRWlfJ3I3FHQvCYFDX95xHsl5brZ3Vkp UAfRPpJmJYfIzhfj7kQZQFJ+mCIfRI0jb+6VyF/u9/MaicfMes4YlUwKEUGBbx+f rrUmEilQCZd3Sw== =Wnux -----END PGP SIGNATURE----- commit 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a Author: Thomas Weißschuh <linux@weissschuh.net> Date: Thu Oct 12 00:37:38 2023 +0200 tools/nolibc: mark start_c as weak Otherwise the different instances of _start_c from each compilation unit will lead to linker errors: /usr/bin/ld: /tmp/ccSNvRqs.o: in function `_start_c': nolibc-test-foo.c:(.text.nolibc_memset+0x9): multiple definition of `_start_c'; /tmp/ccG25101.o:nolibc-test.c:(.text+0x1ea3): first defined here Fixes: 17336755150b ("tools/nolibc: add new crt.h with _start_c") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/ Link: https://lore.kernel.org/lkml/20231012-nolibc-linkage-test-v1-1-315e682768b4@weissschuh.net/ Acked-by: Willy Tarreau <w@1wt.eu> diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h index a5f33fef1672..a05655b4ce1d 100644 --- a/tools/include/nolibc/crt.h +++ b/tools/include/nolibc/crt.h @@ -13,6 +13,7 @@ const unsigned long *_auxv __attribute__((weak)); static void __stack_chk_init(void); static void exit(int); +__attribute__((weak)) void _start_c(long *sp) { long argc;
On 2023-10-16 09:24:19-0700, Paul E. McKenney wrote: > On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote: > > On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Weißschuh wrote: > > > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote: > > > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote: > > > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > > > > > > [..] > > > > > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > > > > > > please check the lead-in text for sanity. (Everything after the digital > > > > > > signature is automatically generated.) > > > > > > > > > > Looks good. But it's only a listing of the commit subjects, correct? > > > > > > > > Pretty close, just a few added words on the last one. > > > > > > > > So the question is whether there is some larger issue that Linus should > > > > be made aware of. If these are just simple fixes for simple bugs, > > > > we should be good, but yes, I do need to ask. ;-) > > > > > > These are simple fixes for simple bugs. > > > > > > Do you always have to ask specifically or can I just mention it in the > > > pull request in the future? > > > > I would be extremely happy to simply copy text from the pull request > > into the signed tags. ;-) > > > > We would just need to agree on the format. For example, in this case, > > there will eventually be two signed tags, one for the urgent pull > > request early next week and another for the pull request for the upcoming > > merge window. > > > > Proposals for the format? > > Actually, proposals for the signed-tag text for the urgent commits? > Left to myself, I would use the same text shown below that I proposed > last week. Looks good. The tags for urgent PRs seem good with one item per patch. I guess for normal PRs one item per series would be fine. > > Thanx, Paul > > ------------------------------------------------------------------------ > > tag urgent/nolibc.2023.10.12a > Tagger: Paul E. McKenney <paulmck@kernel.org> > Date: Thu Oct 12 10:50:08 2023 -0700 > > Urgent pull request for nolibc into v6.6 > > This pull request contains the following fixes: > > o tools/nolibc: i386: Fix a stack misalign bug on _start > > o MAINTAINERS: nolibc: update tree location > > o tools/nolibc: mark start_c as weak to avoid linker errors > [..]
On Tue, Oct 17, 2023 at 12:03:41AM +0200, Thomas Weißschuh wrote: > On 2023-10-16 09:24:19-0700, Paul E. McKenney wrote: > > On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote: > > > On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Weißschuh wrote: > > > > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote: > > > > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote: > > > > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote: > > > > > > > [..] > > > > > > > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so > > > > > > > please check the lead-in text for sanity. (Everything after the digital > > > > > > > signature is automatically generated.) > > > > > > > > > > > > Looks good. But it's only a listing of the commit subjects, correct? > > > > > > > > > > Pretty close, just a few added words on the last one. > > > > > > > > > > So the question is whether there is some larger issue that Linus should > > > > > be made aware of. If these are just simple fixes for simple bugs, > > > > > we should be good, but yes, I do need to ask. ;-) > > > > > > > > These are simple fixes for simple bugs. > > > > > > > > Do you always have to ask specifically or can I just mention it in the > > > > pull request in the future? > > > > > > I would be extremely happy to simply copy text from the pull request > > > into the signed tags. ;-) > > > > > > We would just need to agree on the format. For example, in this case, > > > there will eventually be two signed tags, one for the urgent pull > > > request early next week and another for the pull request for the upcoming > > > merge window. > > > > > > Proposals for the format? > > > > Actually, proposals for the signed-tag text for the urgent commits? > > Left to myself, I would use the same text shown below that I proposed > > last week. > > Looks good. > > The tags for urgent PRs seem good with one item per patch. You got it! urgent/nolibc.2023.10.16a > I guess for normal PRs one item per series would be fine. That makes a lot of sense -- with a non-urgent series, there should be some sort of development theme. I immediately see the list shown below. Please let me know of any needed adjustments. Thanx, Paul ------------------------------------------------------------------------ Add stdarg.h. Optimize x86 string functions and remove unused internal functions. Adjust compiler flags to avoid accidental reliance on system header files, to avoid false-positive warnings, and to allow building 32-bit i386 with multi-architecture compilers. Pass initrd to qemu separately from the kernel image to avoid needless kernel relinks. Make ppc64le use qemu-system-ppc64 in order to provide bi-endian support. Create varargs __nolibc_enosys() function to avoid false-positive compiler warnings for unimplemented system calls. Rely on kernel system-call-number definitions to avoid breaking common-code userspace. Automatrically determine whether pselect6() is required to avoid a bit of manual coding. Add support for C-language constructors and destructors. Drop redundant tests. Add tests for nolibc programs having multiple .o files.
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index af60e07d3c12..2600b4f3bed3 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -171,17 +171,17 @@ sysroot/$(ARCH)/include: $(Q)mv sysroot/sysroot sysroot/$(ARCH) ifneq ($(NOLIBC_SYSROOT),0) -nolibc-test: nolibc-test.c sysroot/$(ARCH)/include +nolibc-test: nolibc-test.c nolibc-test-linkage.c sysroot/$(ARCH)/include $(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \ - -nostdlib -nostdinc -static -Isysroot/$(ARCH)/include $< -lgcc + -nostdlib -nostdinc -static -Isysroot/$(ARCH)/include nolibc-test.c nolibc-test-linkage.c -lgcc else -nolibc-test: nolibc-test.c +nolibc-test: nolibc-test.c nolibc-test-linkage.c $(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \ - -nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc + -nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc nolibc-test.c nolibc-test-linkage.c -lgcc endif -libc-test: nolibc-test.c - $(QUIET_CC)$(HOSTCC) -o $@ $< +libc-test: nolibc-test.c nolibc-test-linkage.c + $(QUIET_CC)$(HOSTCC) -o $@ nolibc-test.c nolibc-test-linkage.c # local libc-test run-libc-test: libc-test diff --git a/tools/testing/selftests/nolibc/nolibc-test-linkage.c b/tools/testing/selftests/nolibc/nolibc-test-linkage.c new file mode 100644 index 000000000000..871db3d22713 --- /dev/null +++ b/tools/testing/selftests/nolibc/nolibc-test-linkage.c @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#include "nolibc-test-linkage.h" + +#ifndef NOLIBC +#include <stdio.h> +#ifndef _NOLIBC_STDIO_H +/* standard libcs need more includes */ +#include <errno.h> +#endif +#endif + +void *linkage_test_errno_addr(void) +{ + return &errno; +} + +int linkage_test_constructor_test_value; + +__attribute__((constructor)) +static void constructor1(void) +{ + linkage_test_constructor_test_value = 2; +} + +__attribute__((constructor)) +static void constructor2(void) +{ + linkage_test_constructor_test_value *= 3; +} diff --git a/tools/testing/selftests/nolibc/nolibc-test-linkage.h b/tools/testing/selftests/nolibc/nolibc-test-linkage.h new file mode 100644 index 000000000000..c66473070d73 --- /dev/null +++ b/tools/testing/selftests/nolibc/nolibc-test-linkage.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _NOLIBC_TEST_LINKAGE_H +#define _NOLIBC_TEST_LINKAGE_H + +void *linkage_test_errno_addr(void); +extern int linkage_test_constructor_test_value; + +#endif /* _NOLIBC_TEST_LINKAGE_H */ diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c index 8da7f15d010e..2f10541e6f38 100644 --- a/tools/testing/selftests/nolibc/nolibc-test.c +++ b/tools/testing/selftests/nolibc/nolibc-test.c @@ -41,6 +41,8 @@ #endif #endif +#include "nolibc-test-linkage.h" + /* for the type of int_fast16_t and int_fast32_t, musl differs from glibc and nolibc */ #define SINT_MAX_OF_TYPE(type) (((type)1 << (sizeof(type) * 8 - 2)) - (type)1 + ((type)1 << (sizeof(type) * 8 - 2))) #define SINT_MIN_OF_TYPE(type) (-SINT_MAX_OF_TYPE(type) - 1) @@ -647,6 +649,8 @@ int run_startup(int min, int max) CASE_TEST(auxv_addr); EXPECT_PTRGT(test_auxv != (void *)-1, test_auxv, brk); break; CASE_TEST(auxv_AT_UID); EXPECT_EQ(1, getauxval(AT_UID), getuid()); break; CASE_TEST(constructor); EXPECT_EQ(1, constructor_test_value, 2); break; + CASE_TEST(linkage_errno); EXPECT_PTREQ(1, linkage_test_errno_addr(), &errno); break; + CASE_TEST(linkage_constr); EXPECT_EQ(1, linkage_test_constructor_test_value, 6); break; case __LINE__: return ret; /* must be last */ /* note: do not set any defaults so as to permit holes above */