From: Kris Van Hees <kris.van.hees@oracle.com>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
Nick Alcock <nick.alcock@oracle.com>,
Alan Maguire <alan.maguire@oracle.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Jiri Olsa <olsajiri@gmail.com>,
Elena Zannoni <elena.zannoni@oracle.com>
Subject: Re: [PATCH v8 2/4] kbuild: generate offset range data for builtin modules
Date: Fri, 23 Aug 2024 13:06:06 -0400 [thread overview]
Message-ID: <ZsjBfjAuC5t/2Cex@oracle.com> (raw)
In-Reply-To: <20240823165329.GA3911831@google.com>
On Fri, Aug 23, 2024 at 04:53:29PM +0000, Sami Tolvanen wrote:
> Hi Kris,
>
> On Thu, Aug 22, 2024 at 02:19:39PM -0400, Kris Van Hees wrote:
> > diff --git a/scripts/generate_builtin_ranges.awk b/scripts/generate_builtin_ranges.awk
> > new file mode 100755
> > index 000000000000..68df05fd3036
> > --- /dev/null
> > +++ b/scripts/generate_builtin_ranges.awk
> > @@ -0,0 +1,505 @@
> > +#!/usr/bin/gawk -f
> > +# SPDX-License-Identifier: GPL-2.0
> > +# generate_builtin_ranges.awk: Generate address range data for builtin modules
> > +# Written by Kris Van Hees <kris.van.hees@oracle.com>
> > +#
> > +# Usage: generate_builtin_ranges.awk modules.builtin vmlinux.map \
> > +# vmlinux.o.map > modules.builtin.ranges
> > +#
> > +
> > +# Return the module name(s) (if any) associated with the given object.
> > +#
> > +# If we have seen this object before, return information from the cache.
> > +# Otherwise, retrieve it from the corresponding .cmd file.
> > +#
> > +function get_module_info(fn, mod, obj, s) {
> > + if (fn in omod)
> > + return omod[fn];
> > +
> > + if (match(fn, /\/[^/]+$/) == 0)
> > + return "";
> > +
> > + obj = fn;
> > + mod = "";
> > + fn = substr(fn, 1, RSTART) "." substr(fn, RSTART + 1) ".cmd";
> > + if (getline s <fn == 1) {
> > + if (match(s, /DKBUILD_MODFILE=['"]+[^'"]+/) > 0) {
> > + mod = substr(s, RSTART + 16, RLENGTH - 16);
> > + gsub(/['"]/, "", mod);
> > + }
> > + }
>
> This doesn't work with built-in Rust modules because there's no
> -DKBUILD_MODFILE flag passed to the compiler. The .cmd files do have
> RUST_MODFILE set though, so presumably you could match that too?
Thanks for looking at the patch series. I'll look into this.
Is there a reason why Rust modules are using RUST_MODFILE rather than also
using KBUILD_MODFILE as the macro to pass information about what module(s)
the object belongs to?
Thanksm,
Kris
next prev parent reply other threads:[~2024-08-23 17:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 4:06 [PATCH v7 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects Kris Van Hees
2024-08-21 4:06 ` [PATCH v7 2/4] kbuild: generate offset range data for builtin modules Kris Van Hees
2024-08-22 17:34 ` Masahiro Yamada
2024-08-21 4:06 ` [PATCH v7 3/4] scripts: add verifier script for builtin module range data Kris Van Hees
2024-08-22 17:35 ` Masahiro Yamada
2024-08-21 4:07 ` [PATCH v7 4/4] module: add install target for modules.builtin.ranges Kris Van Hees
2024-08-21 14:40 ` [PATCH v7 0/4] Generate address range data for built-in modules Kris Van Hees
2024-08-22 18:19 ` [PATCH v8 " Kris Van Hees
2024-08-22 18:19 ` [PATCH v8 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects Kris Van Hees
2024-08-23 17:37 ` Masahiro Yamada
2024-08-22 18:19 ` [PATCH v8 2/4] kbuild: generate offset range data for builtin modules Kris Van Hees
2024-08-23 16:53 ` Sami Tolvanen
2024-08-23 17:06 ` Kris Van Hees [this message]
2024-08-23 17:23 ` Sami Tolvanen
2024-08-24 16:44 ` Miguel Ojeda
2024-08-22 18:19 ` [PATCH v8 3/4] scripts: add verifier script for builtin module range data Kris Van Hees
2024-08-22 18:19 ` [PATCH v8 4/4] module: add install target for modules.builtin.ranges Kris Van Hees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZsjBfjAuC5t/2Cex@oracle.com \
--to=kris.van.hees@oracle.com \
--cc=alan.maguire@oracle.com \
--cc=elena.zannoni@oracle.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nick.alcock@oracle.com \
--cc=olsajiri@gmail.com \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.