Message ID | 20230210152622.92912-1-andrea.righi@canonical.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1019568wrn; Fri, 10 Feb 2023 07:32:38 -0800 (PST) X-Google-Smtp-Source: AK7set+WJz3zb2VBCfi4ByjXnm+DLvAvjy0yiCIvBgCML/aqInVJMYYvafbMdxDbnwjeWnDbHXY+ X-Received: by 2002:a17:902:e3c2:b0:198:f907:2a9b with SMTP id r2-20020a170902e3c200b00198f9072a9bmr11192439ple.37.1676043157815; Fri, 10 Feb 2023 07:32:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676043157; cv=none; d=google.com; s=arc-20160816; b=Cl0zjTN8mIfYWD97I+jToF921+/UJEFs5SSjgseP/A6bsaBTtu/A87Us7yzV4LIcxI bfkhFuFbJ7nicucXXUnRnko01HEss4yeGJKaJ0V74/5iVY7icPRIID3P9vBOout+zTT8 4ocQHXgUS+yXG6/4GMJyq5Qwab00BhuFIeuWgUskrJ14rrEhsfuVRwAAXKDvoZf2LUnU SmsPqfm7F+izIA7cwfmOm2ppHnezjqlbg84UMzhd3yGiqz4kkS+tGVqAqDGdwJhVwVS1 QsZv/3L49GYRg3Ezd/8mnpkqD2vAzPL1Vh8TdyBcKQMcQKk6KxTSoD+XdT+udx3iOlmM +MQA== 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=1krz5gzGk/IBtH/mXLuEk6jDYq6rFyZJFvG5QeiBg8o=; b=FFJzFRQ6jaTc/qU1uToBBcL9kebNNsRx6b6itcQKIrLKohyLvFOMrnoTTdsx4yIyJQ pMbC5a0r8B/IURzwgMiCqsec7ao/uKsjhJgGJ3KUk6kVL1lLG0vND9eejepvjcvHcyvA D5g6jA+rhaUPxztMJVIcEr8UkpO37j44um4YItZrlVd0S7vEBi5miW0kYm5QrUYRVJn7 1/lLQbSYjSvTyx+B2jhjJTHj4WWexIBjOhniS0xjjFJrShNPkrDAX3faJmBB8vKRv/db RtVozt1fB252DT8bkjgrUdmq1l97lnQjdelAko8Lyf3xne/DQcIQmxQ7G1f78ef3FIEg dyag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=v74G2Pec; 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 i9-20020a17090332c900b0019a59c52fd3si5530303plr.508.2023.02.10.07.32.25; Fri, 10 Feb 2023 07:32:37 -0800 (PST) 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=v74G2Pec; 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 S232709AbjBJP0a (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Fri, 10 Feb 2023 10:26:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232608AbjBJP02 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Feb 2023 10:26:28 -0500 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 5C2612823A for <linux-kernel@vger.kernel.org>; Fri, 10 Feb 2023 07:26:26 -0800 (PST) Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (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 903603F194 for <linux-kernel@vger.kernel.org>; Fri, 10 Feb 2023 15:26:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1676042784; bh=1krz5gzGk/IBtH/mXLuEk6jDYq6rFyZJFvG5QeiBg8o=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=v74G2PecauTgOs8g1wxUyoHnBx7B07hjRdLD8EAFTj9KumvRrbgjjq+ZB87UQRXCi aBJNDBKVIln/YZC8b3TrEtIURsVGC2AgTAAo5MYZAn62+Mv5JDbqgGSBhX1DCgbl/9 QKA+CwwHpQfdUtaHL5QI+UNEVehsX05kpY3R6mSbpFjcqZ85wCSZr4WhBo3dwJaJWD lppzjQ9rg2k1jlRwFlLP24wjvU3SnHpfO7Urun4eonpEkgx5vHKQrcAV9gWPv2Ey7q hSR1reZDrv/COKPY+8daoB1ONDBqk5gezfq+jHIGECr20AwFxGtpvL9h+7KXJTpu/T 1r3sjBY274/JQ== Received: by mail-ej1-f69.google.com with SMTP id l18-20020a1709067d5200b008af415fdd80so3165362ejp.21 for <linux-kernel@vger.kernel.org>; Fri, 10 Feb 2023 07:26:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=1krz5gzGk/IBtH/mXLuEk6jDYq6rFyZJFvG5QeiBg8o=; b=bLsZj8Ggd90KDr/2+1JM6QueXvsvRrTwxDc0gpe/DfmnHIdJdoy0Yv3+o84WdSFy/W l2L+SAXSGRViPZt+AkrW50+idxU8jyjCNGgOAUQvzVT2dbdQJ46nr4/txYQNz2NlpA9k gXo9D5qNc99JvUYoMIrYIT+ubjoXkD43m7vZOCt1OXkWJ56UYZAwGQg0AMqEw+hsGeyK iRy0WxwlMJ/VoIDdhakkiliOqSasUkDY6UpPqP95H4W9K4ncPtu9ScrVIna6ukAVCnTY noy3Akbic+OvpCHh/H1G211kb5anrZNjtw+a4nHag7VMSqlm7dB5oC1nyuX+UIoZWuZZ ZmuQ== X-Gm-Message-State: AO0yUKWacR6GUZRUWKvDv1NT/G45wLfjKbyAJoAhccvG+cQEfuyV8qO3 plVIfCPqonAIlmmThKirJEIApnkUXyFxuEme1nHqKYOCDNU5XGtTbDfxl8ecBquvpQNAyYprWA6 L/yTqeZ37azJF3NnZ3E/LA7W7Sp/L7EfKAxmZ5+82Lg== X-Received: by 2002:a17:906:80cd:b0:8aa:a445:8215 with SMTP id a13-20020a17090680cd00b008aaa4458215mr14116905ejx.70.1676042784261; Fri, 10 Feb 2023 07:26:24 -0800 (PST) X-Received: by 2002:a17:906:80cd:b0:8aa:a445:8215 with SMTP id a13-20020a17090680cd00b008aaa4458215mr14116888ejx.70.1676042784093; Fri, 10 Feb 2023 07:26:24 -0800 (PST) Received: from righiandr-XPS-13-7390.homenet.telecomitalia.it (host-87-7-128-191.retail.telecomitalia.it. [87.7.128.191]) by smtp.gmail.com with ESMTPSA id f20-20020a170906c09400b00872c0bccab2sm2507689ejz.35.2023.02.10.07.26.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Feb 2023 07:26:23 -0800 (PST) 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>, bjorn3_gh@protonmail.com, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] rust: fix regexp in scripts/is_rust_module.sh Date: Fri, 10 Feb 2023 16:26:22 +0100 Message-Id: <20230210152622.92912-1-andrea.righi@canonical.com> X-Mailer: git-send-email 2.37.2 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 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: <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?1757458630236105323?= X-GMAIL-MSGID: =?utf-8?q?1757458630236105323?= |
Series |
rust: fix regexp in scripts/is_rust_module.sh
|
|
Commit Message
Andrea Righi
Feb. 10, 2023, 3:26 p.m. UTC
nm can use "R" or "r" to show read-only data sections, but
scripts/is_rust_module.sh can only recognize "r", so with some versions
of binutils it can fail to detect if a module is a Rust module or not.
Right now we're using this script only to determine if we need to skip
BTF generation (that is disabled globally if CONFIG_RUST is enabled),
but it's still nice to fix this script to do the proper job.
Moreover, with this patch applied I can also relax the constraint of
"RUST depends on !DEBUG_INFO_BTF" and build a kernel with Rust and BTF
enabled at the same time (of course BTF generation is still skipped for
Rust modules).
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
---
scripts/is_rust_module.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
> nm can use "R" or "r" to show read-only data sections, but > scripts/is_rust_module.sh can only recognize "r", so with some versions > of binutils it can fail to detect if a module is a Rust module or not. > > Right now we're using this script only to determine if we need to skip > BTF generation (that is disabled globally if CONFIG_RUST is enabled), > but it's still nice to fix this script to do the proper job. > > Moreover, with this patch applied I can also relax the constraint of > "RUST depends on !DEBUG_INFO_BTF" and build a kernel with Rust and BTF > enabled at the same time (of course BTF generation is still skipped for > Rust modules). > > Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
On Fri, Feb 10, 2023 at 4:26 PM Andrea Righi <andrea.righi@canonical.com> wrote: > > nm can use "R" or "r" to show read-only data sections, but > scripts/is_rust_module.sh can only recognize "r", so with some versions > of binutils it can fail to detect if a module is a Rust module or not. Do you know which versions? If so, it would be nice to document it here. > Moreover, with this patch applied I can also relax the constraint of > "RUST depends on !DEBUG_INFO_BTF" and build a kernel with Rust and BTF > enabled at the same time (of course BTF generation is still skipped for > Rust modules). Even if that build succeeds, can you load the modules? i.e. the constraint was there due to https://github.com/Rust-for-Linux/linux/issues/735. Also Cc'ing Daniel, Eric and Martin since they are the ones working on this. Cheers, Miguel
On Mon, 13 Feb 2023 at 13:19, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Fri, Feb 10, 2023 at 4:26 PM Andrea Righi <andrea.righi@canonical.com> wrote: > > > > nm can use "R" or "r" to show read-only data sections, but > > scripts/is_rust_module.sh can only recognize "r", so with some versions > > of binutils it can fail to detect if a module is a Rust module or not. > > Do you know which versions? If so, it would be nice to document it here. > > > Moreover, with this patch applied I can also relax the constraint of > > "RUST depends on !DEBUG_INFO_BTF" and build a kernel with Rust and BTF > > enabled at the same time (of course BTF generation is still skipped for > > Rust modules). > > Even if that build succeeds, can you load the modules? i.e. the > constraint was there due to > https://github.com/Rust-for-Linux/linux/issues/735. > > Also Cc'ing Daniel, Eric and Martin since they are the ones working on this. Don't have any issues with the change. Seems simple enough! Reviewed-by: Eric Curtin <ecurtin@redhat.com> > > Cheers, > Miguel >
On Fri, Feb 10, 2023 at 4:26 PM Andrea Righi <andrea.righi@canonical.com> wrote: > nm can use "R" or "r" to show read-only data sections, but > scripts/is_rust_module.sh can only recognize "r", so with some versions > of binutils it can fail to detect if a module is a Rust module or not. As __IS_RUST_MODULE can be a dynamic symbol too this change seems reasonable to merge. Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
On Mon, Feb 13, 2023 at 02:19:38PM +0100, Miguel Ojeda wrote: > On Fri, Feb 10, 2023 at 4:26 PM Andrea Righi <andrea.righi@canonical.com> wrote: > > > > nm can use "R" or "r" to show read-only data sections, but > > scripts/is_rust_module.sh can only recognize "r", so with some versions > > of binutils it can fail to detect if a module is a Rust module or not. > > Do you know which versions? If so, it would be nice to document it here. > > > Moreover, with this patch applied I can also relax the constraint of > > "RUST depends on !DEBUG_INFO_BTF" and build a kernel with Rust and BTF > > enabled at the same time (of course BTF generation is still skipped for > > Rust modules). > > Even if that build succeeds, can you load the modules? i.e. the > constraint was there due to > https://github.com/Rust-for-Linux/linux/issues/735. This patch simply fixes scripts/is_rust_module.sh to recognize Rust modules from "regular" C modules with certain versions of binutils, so that BTF generation is properly skipped for Rust modules. In this way both C and Rust modules can be loaded correctly (at least in my tests I'm able load both with CONFIG_DEBUG_INFO_BTF enabled). I haven't dropped the "RUST depends on !DEBUG_INFO_BTF" yet, but I think with this fix is applied we can relax this constraint. -Andrea > > Also Cc'ing Daniel, Eric and Martin since they are the ones working on this. > > Cheers, > Miguel
On Mon, Feb 13, 2023 at 4:01 PM Andrea Righi <andrea.righi@canonical.com> wrote: > > In this way both C and Rust modules can be loaded correctly (at least in > my tests I'm able load both with CONFIG_DEBUG_INFO_BTF enabled). > > I haven't dropped the "RUST depends on !DEBUG_INFO_BTF" yet, but I think > with this fix is applied we can relax this constraint. Yeah, but the constraint was there for other reasons, so I got surprised when I read that in the commit message. Apparently, Martin cannot load the modules (https://lore.kernel.org/rust-for-linux/20230213151339.661225-1-yakoyoku@gmail.com/), but you can. Cheers, Miguel
On Fri, Feb 10, 2023 at 4:26 PM Andrea Righi <andrea.righi@canonical.com> wrote: > > nm can use "R" or "r" to show read-only data sections, but > scripts/is_rust_module.sh can only recognize "r", so with some versions > of binutils it can fail to detect if a module is a Rust module or not. Applied to `rust-fixes`. Thanks! Cheers, Miguel
diff --git a/scripts/is_rust_module.sh b/scripts/is_rust_module.sh index 28b3831a7593..464761a7cf7f 100755 --- a/scripts/is_rust_module.sh +++ b/scripts/is_rust_module.sh @@ -13,4 +13,4 @@ set -e # # 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]+ r _R[^[:space:]]+16___IS_RUST_MODULE[^[:space:]]*$' +${NM} "$*" | grep -qE '^[0-9a-fA-F]+ [Rr] _R[^[:space:]]+16___IS_RUST_MODULE[^[:space:]]*$'