Message ID | 20230704052136.155445-1-andrea.righi@canonical.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp987788vqx; Mon, 3 Jul 2023 22:30:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5fDjquysH5AvH6p1jE5N61pioPWmkJ4xQ4eUvuyOCij4LQrrQS/0a8EqOj9xi2zmbcvhtl X-Received: by 2002:a54:4e81:0:b0:39e:757b:8a6c with SMTP id c1-20020a544e81000000b0039e757b8a6cmr10178373oiy.3.1688448637420; Mon, 03 Jul 2023 22:30:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688448637; cv=none; d=google.com; s=arc-20160816; b=M3v/raFZqzzWhCr/BRhd2QwbQO0QEwgGeCyLF2Sek5FMYnl8uav0HjenMYAwLaznz/ 33j88AZfaRhVw7SLSqejfJOifyGanUomsHqbTgWlqMf5CmKzT7ta9qBNVQf93hv/o+DC 4/IACRP0GC349hCY/3fHUMfxBbTQvvCl5p+b+YEeTKOOrSu8sRTff21AwBE/czr1jP0b FKFpK22w9Dd6L6Y9f/IPT9j/z8JhRv6a4Yi8d4Vu2bRQIMw4tVjZz/T32uRnVltR1qO6 AnALiobqBXrrKjkLnvgS3VChRgHPEvBrtXkGxlJVtQ2CfCgg9FataPEZ05io8rJVxJZE Ri/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=1v+am1Z8ymQUGghyM5chvEt9+BuF/dKqLqYQx56m9zI=; fh=P41QLok0kfvdOv+5Xnd/mghfKa2n/Z9EYBJSg8Kp/vI=; b=yAOawpK1j+qI8CxM8mFqjeycsGQcJX6mhEZR1uGlCDmMcAldqT8wah5AybdMpLme9Z IgqlyvNAq40/Nxe8FNPpSZmOzIMbbexnjWkQrEIbJHh2SP/zC5XmNdg+bB4fO1V6OSNH 2o7IifGstgQS027+CDKrHMPuxxxKH7FLY3piVI02x7JowKsau6jyoz7MzNzth+HUcffd eutrqAW71yvAsVvrchFXGScvJvRR81EHtAAS5cCl7m4VOsHcR+Z+oei3eCXjhNr+Nl1N 3htud5Fw+hfkc8ohlew4a7jt5+vCiHO6XwIaptO7XSegVhT0it+4gDCJxCMVWj5/3RJh nfNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b="vB2FndN/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bk13-20020a056a02028d00b005539d3ab914si21260741pgb.694.2023.07.03.22.30.23; Mon, 03 Jul 2023 22:30:37 -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; dkim=pass header.i=@canonical.com header.s=20210705 header.b="vB2FndN/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230137AbjGDFVs (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Tue, 4 Jul 2023 01:21:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229994AbjGDFVr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 4 Jul 2023 01:21:47 -0400 Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4ED8E52 for <linux-kernel@vger.kernel.org>; Mon, 3 Jul 2023 22:21:41 -0700 (PDT) Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id D2EC43F734 for <linux-kernel@vger.kernel.org>; Tue, 4 Jul 2023 05:21:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1688448099; bh=1v+am1Z8ymQUGghyM5chvEt9+BuF/dKqLqYQx56m9zI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=vB2FndN/lPH3vxR3Bwz6s+54wM8vqm/pYmDno2kkJVCm2Zl5magnsntALQ6gQ1nNM gn5S15ylr0Z2UseHRDLjEJnSyzmhZ7bx1FtdzlA6nV1j/AQbS+1DCcTNOfwkzWA1Ae rKfaRJKWf13iaFKBtbMd2WcYx5zu9TWVqZFEIRC809dB/rPev2E49Fd8Vwj+J2kp3Q I9RMx9eSahCo9s/0rfDs3vCR9+4gnuF9PhqM21+GHZWGtVYDJTP3NqFnJXdw9T/F7U 7vREIpX31zGFPc/Os6Jk6cLI1D0DO5ZLS3RKLwR3UBwwDvu7Qbcg60CZz86iejqSHj GF+E5FZyQxcww== Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-9874fbf5c95so592377566b.1 for <linux-kernel@vger.kernel.org>; Mon, 03 Jul 2023 22:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688448098; x=1691040098; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1v+am1Z8ymQUGghyM5chvEt9+BuF/dKqLqYQx56m9zI=; b=HUkekSVtFhZgnKH1U7YbKPe5X9HVHVfhG9DBHACEh7gOUhWdQe3wA7FHe7Fu27i3LW he85ukvKQ20VcTM0kesGCcAYvGHl/1r7Pbz8dYs/mQwG1qE6Io7BAlCxpQ3bze5J4J4r lnYXowSfNq2am148ZTdVrNntu+VHdlAhry+tr4UVaPilBiKLEUK/XokB7k6xI+7/qjCI pbDH93rU35woTJj39LSBF8j7U4SxVoWhg4KbAvcgbQBWb+9sjgfVO1hCb4A2okTd/Pce EOUV8RzEEj2dxbMN6ZWj/kIEIx+0KUM2p3gQbwcN1OhK7RXauHIm3TN3YmYsxQYUgikK KPDA== X-Gm-Message-State: AC+VfDy+GW08sYJYcsWJmMTmTJfoHdo6sghTIg9LSE3Ix3/nZLQpt2bH kolpVtehHjXOtIErWRtErGUNhwuDroMXKhTmCJUTv6oWiY2S1BsMYdOizwwNG8iHnaPROyPGlOw LRpp2uUjf81gIHuXPouqWJAfmfPKISB04LoypQ6xeaQ== X-Received: by 2002:a17:907:6e1b:b0:98e:1c4b:10e2 with SMTP id sd27-20020a1709076e1b00b0098e1c4b10e2mr13287223ejc.20.1688448098176; Mon, 03 Jul 2023 22:21:38 -0700 (PDT) X-Received: by 2002:a17:907:6e1b:b0:98e:1c4b:10e2 with SMTP id sd27-20020a1709076e1b00b0098e1c4b10e2mr13287209ejc.20.1688448097892; Mon, 03 Jul 2023 22:21:37 -0700 (PDT) Received: from righiandr-XPS-13-7390.homenet.telecomitalia.it (host-95-234-206-203.retail.telecomitalia.it. [95.234.206.203]) by smtp.gmail.com with ESMTPSA id a10-20020a17090640ca00b0098e025cda3bsm12706377ejk.141.2023.07.03.22.21.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jul 2023 22:21:37 -0700 (PDT) From: Andrea Righi <andrea.righi@canonical.com> To: Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com> Cc: Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>, =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, Benno Lossin <benno.lossin@proton.me>, Masahiro Yamada <masahiroy@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, Tom Rix <trix@redhat.com>, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev Subject: [PATCH] btf, scripts: rust: drop is_rust_module.sh Date: Tue, 4 Jul 2023 07:21:36 +0200 Message-Id: <20230704052136.155445-1-andrea.righi@canonical.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770466718122926504?= X-GMAIL-MSGID: =?utf-8?q?1770466718122926504?= |
Series |
btf, scripts: rust: drop is_rust_module.sh
|
|
Commit Message
Andrea Righi
July 4, 2023, 5:21 a.m. UTC
With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole")
we are now able to use pahole directly to identify Rust compilation
units (CUs) and exclude them from generating BTF debugging information
(when DEBUG_INFO_BTF is enabled).
And if pahole doesn't support the --lang-exclude flag, we can't enable
both RUST and DEBUG_INFO_BTF at the same time.
So, in any case, the script is_rust_module.sh is just redundant and we
can drop it.
NOTE: we may also be able to drop the "Rust loadable module" mark
inside Rust modules, but it seems safer to keep it for now to make sure
we are not breaking any external tool that may potentially rely on it.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
---
rust/macros/module.rs | 2 +-
scripts/Makefile.modfinal | 2 --
scripts/is_rust_module.sh | 16 ----------------
3 files changed, 1 insertion(+), 19 deletions(-)
delete mode 100755 scripts/is_rust_module.sh
Comments
On 7/4/23 02:21, Andrea Righi wrote: > With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole") > we are now able to use pahole directly to identify Rust compilation > units (CUs) and exclude them from generating BTF debugging information > (when DEBUG_INFO_BTF is enabled). > > And if pahole doesn't support the --lang-exclude flag, we can't enable > both RUST and DEBUG_INFO_BTF at the same time. > > So, in any case, the script is_rust_module.sh is just redundant and we > can drop it. > > NOTE: we may also be able to drop the "Rust loadable module" mark > inside Rust modules, but it seems safer to keep it for now to make sure > we are not breaking any external tool that may potentially rely on it. Keep it, I think it can be useful with tooling like kmod. > > Signed-off-by: Andrea Righi <andrea.righi@canonical.com> > --- > [...] Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
On Tue, Jul 4, 2023 at 7:21 AM Andrea Righi <andrea.righi@canonical.com> wrote: > > With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole") > we are now able to use pahole directly to identify Rust compilation > units (CUs) and exclude them from generating BTF debugging information > (when DEBUG_INFO_BTF is enabled). > > And if pahole doesn't support the --lang-exclude flag, we can't enable > both RUST and DEBUG_INFO_BTF at the same time. > > So, in any case, the script is_rust_module.sh is just redundant and we > can drop it. > > NOTE: we may also be able to drop the "Rust loadable module" mark > inside Rust modules, but it seems safer to keep it for now to make sure > we are not breaking any external tool that may potentially rely on it. Just to recall the history of these changes: - The script got added in order to skip the BTF generation in the `BTF [M]` step (under `DEBUG_INFO_BTF_MODULES`, which depends on `DEBUG_INFO_BTF`). - A few months later, it was noticed that C modules couldn't be loaded if Rust was enabled, due to the base BTF info in `vmlinux`. That triggered the eventual addition of `--lang_exclude=` to `pahole`, but meanwhile, we made `DEBUG_INFO_BTF` and `RUST` exclusive. - Now, this patch removes the script because having a newer `pahole` also correctly skips the Rust CUs in the `BTF [M]` steps (i.e. and not just the `vmlinux` one), since we pass `--lang_exclude=` to both cases (`link-vmlinux.sh` and `Makefile.modfinal`), if I understand correctly (the script could, in principle, have been removed even before `pahole` got the new feature, given the exclusivity of the options). If this is all correct, then the patch looks good to me. I am Cc'ing Arnaldo, Martin and the BPF list. If this goes through the Rust tree, I will also pick the older `Reviewed-by`s. Thanks! Cheers, Miguel
On Tue, Jul 11, 2023 at 04:39:27PM +0200, Miguel Ojeda wrote: > On Tue, Jul 4, 2023 at 7:21 AM Andrea Righi <andrea.righi@canonical.com> wrote: > > > > With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole") > > we are now able to use pahole directly to identify Rust compilation > > units (CUs) and exclude them from generating BTF debugging information > > (when DEBUG_INFO_BTF is enabled). > > > > And if pahole doesn't support the --lang-exclude flag, we can't enable > > both RUST and DEBUG_INFO_BTF at the same time. > > > > So, in any case, the script is_rust_module.sh is just redundant and we > > can drop it. > > > > NOTE: we may also be able to drop the "Rust loadable module" mark > > inside Rust modules, but it seems safer to keep it for now to make sure > > we are not breaking any external tool that may potentially rely on it. > > Just to recall the history of these changes: > > - The script got added in order to skip the BTF generation in the > `BTF [M]` step (under `DEBUG_INFO_BTF_MODULES`, which depends on > `DEBUG_INFO_BTF`). > > - A few months later, it was noticed that C modules couldn't be > loaded if Rust was enabled, due to the base BTF info in `vmlinux`. > That triggered the eventual addition of `--lang_exclude=` to `pahole`, > but meanwhile, we made `DEBUG_INFO_BTF` and `RUST` exclusive. > > - Now, this patch removes the script because having a newer `pahole` > also correctly skips the Rust CUs in the `BTF [M]` steps (i.e. and not > just the `vmlinux` one), since we pass `--lang_exclude=` to both cases > (`link-vmlinux.sh` and `Makefile.modfinal`), if I understand correctly > (the script could, in principle, have been removed even before > `pahole` got the new feature, given the exclusivity of the options). The history looks correct to me. Also, note that, if pahole doesn't support the new `--lang-exclude=`, we have `RUST` depending on `!DEBUG_INFO_BTF`, so we fallback the old "exclusivity" mode between BTF and Rust and, again, the script is not needed. As you correctly say, in principle, we could have removed the script even before the new `pahole`. > > If this is all correct, then the patch looks good to me. I am Cc'ing > Arnaldo, Martin and the BPF list. > > If this goes through the Rust tree, I will also pick the older `Reviewed-by`s. > > Thanks! > > Cheers, > Miguel Thanks, -Andrea
Hi Miguel, Andrea, On Tue, Jul 11, 2023 at 04:39:27PM +0200, Miguel Ojeda wrote: > On Tue, Jul 4, 2023 at 7:21 AM Andrea Righi <andrea.righi@canonical.com> wrote: > > > > With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole") > > we are now able to use pahole directly to identify Rust compilation > > units (CUs) and exclude them from generating BTF debugging information > > (when DEBUG_INFO_BTF is enabled). > > > > And if pahole doesn't support the --lang-exclude flag, we can't enable > > both RUST and DEBUG_INFO_BTF at the same time. > > > > So, in any case, the script is_rust_module.sh is just redundant and we > > can drop it. > > > > NOTE: we may also be able to drop the "Rust loadable module" mark > > inside Rust modules, but it seems safer to keep it for now to make sure > > we are not breaking any external tool that may potentially rely on it. > > Just to recall the history of these changes: > > - The script got added in order to skip the BTF generation in the > `BTF [M]` step (under `DEBUG_INFO_BTF_MODULES`, which depends on > `DEBUG_INFO_BTF`). > > - A few months later, it was noticed that C modules couldn't be > loaded if Rust was enabled, due to the base BTF info in `vmlinux`. > That triggered the eventual addition of `--lang_exclude=` to `pahole`, > but meanwhile, we made `DEBUG_INFO_BTF` and `RUST` exclusive. > > - Now, this patch removes the script because having a newer `pahole` > also correctly skips the Rust CUs in the `BTF [M]` steps (i.e. and not > just the `vmlinux` one), since we pass `--lang_exclude=` to both cases > (`link-vmlinux.sh` and `Makefile.modfinal`), if I understand correctly > (the script could, in principle, have been removed even before > `pahole` got the new feature, given the exclusivity of the options). > > If this is all correct, then the patch looks good to me. I am Cc'ing > Arnaldo, Martin and the BPF list. I believe I authored the original script. This all sounds right to me. Acked-by: Daniel Xu <dxu@dxuuu.xyz> Thanks, Daniel
On Tue, Jul 4, 2023 at 7:21 AM Andrea Righi <andrea.righi@canonical.com> wrote: > > With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole") > we are now able to use pahole directly to identify Rust compilation > units (CUs) and exclude them from generating BTF debugging information > (when DEBUG_INFO_BTF is enabled). > > And if pahole doesn't support the --lang-exclude flag, we can't enable > both RUST and DEBUG_INFO_BTF at the same time. > > So, in any case, the script is_rust_module.sh is just redundant and we > can drop it. > > NOTE: we may also be able to drop the "Rust loadable module" mark > inside Rust modules, but it seems safer to keep it for now to make sure > we are not breaking any external tool that may potentially rely on it. > > Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Applied to `rust-next` -- thanks everyone, and Andrea and Daniel for confirming my summary/recollection sounded right in the other message. Cheers, Miguel
diff --git a/rust/macros/module.rs b/rust/macros/module.rs index fb1244f8c2e6..d62d8710d77a 100644 --- a/rust/macros/module.rs +++ b/rust/macros/module.rs @@ -199,7 +199,7 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream { /// Used by the printing macros, e.g. [`info!`]. const __LOG_PREFIX: &[u8] = b\"{name}\\0\"; - /// The \"Rust loadable module\" mark, for `scripts/is_rust_module.sh`. + /// The \"Rust loadable module\" mark. // // This may be best done another way later on, e.g. as a new modinfo // key or a new section. For the moment, keep it simple. diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal index fc19f67039bd..b3a6aa8fbe8c 100644 --- a/scripts/Makefile.modfinal +++ b/scripts/Makefile.modfinal @@ -41,8 +41,6 @@ quiet_cmd_btf_ko = BTF [M] $@ cmd_btf_ko = \ if [ ! -f vmlinux ]; then \ printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ - elif [ -n "$(CONFIG_RUST)" ] && $(srctree)/scripts/is_rust_module.sh $@; then \ - printf "Skipping BTF generation for %s because it's a Rust module\n" $@ 1>&2; \ else \ LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ $(RESOLVE_BTFIDS) -b vmlinux $@; \ diff --git a/scripts/is_rust_module.sh b/scripts/is_rust_module.sh deleted file mode 100755 index 464761a7cf7f..000000000000 --- a/scripts/is_rust_module.sh +++ /dev/null @@ -1,16 +0,0 @@ -#!/bin/sh -# SPDX-License-Identifier: GPL-2.0 -# -# is_rust_module.sh module.ko -# -# Returns `0` if `module.ko` is a Rust module, `1` otherwise. - -set -e - -# Using the `16_` prefix ensures other symbols with the same substring -# are not picked up (even if it would be unlikely). The last part is -# used just in case LLVM decides to use the `.` suffix. -# -# In the future, checking for the `.comment` section may be another -# option, see https://github.com/rust-lang/rust/pull/97550. -${NM} "$*" | grep -qE '^[0-9a-fA-F]+ [Rr] _R[^[:space:]]+16___IS_RUST_MODULE[^[:space:]]*$'