From: Masahiro Yamada <masahiroy@kernel.org>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.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 v2 0/6] Generate address range data for built-in modules
Date: Thu, 16 May 2024 11:56:39 +0900 [thread overview]
Message-ID: <CAK7LNARRzGt8EWhRcXnj=2G7E1KOq4E-PGUX53wBoCXAsmSr_g@mail.gmail.com> (raw)
In-Reply-To: <ZkTnwwyTF0WSMmqI@oracle.com>
On Thu, May 16, 2024 at 1:50 AM Kris Van Hees <kris.van.hees@oracle.com> wrote:
>
> On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote:
> > On Sun, May 12, 2024 at 7:42???AM Kris Van Hees <kris.van.hees@oracle.com> wrote:
> > >
> > > Especially for tracing applications, it is convenient to be able to
> > > refer to a symbol using a <module name, symbol name> pair and to be able
> > > to translate an address into a <nodule mname, symbol name> pair. But
> > > that does not work if the module is built into the kernel because the
> > > object files that comprise the built-in module implementation are simply
> > > linked into the kernel image along with all other kernel object files.
> > >
> > > This is especially visible when providing tracing scripts for support
> > > purposes, where the developer of the script targets a particular kernel
> > > version, but does not have control over whether the target system has
> > > a particular module as loadable module or built-in module. When tracing
> > > symbols within a module, referring them by <module name, symbol name>
> > > pairs is both convenient and aids symbol lookup. But that naming will
> > > not work if the module name information is lost if the module is built
> > > into the kernel on the target system.
> > >
> > > Earlier work addressing this loss of information for built-in modules
> > > involved adding module name information to the kallsyms data, but that
> > > required more invasive code in the kernel proper. This work never did
> > > get merged into the kernel tree.
> > >
> > > All that is really needed is knowing whether a given address belongs to
> > > a particular module (or multiple modules if they share an object file).
> > > Or in other words, whether that address falls within an address range
> > > that is associated with one or more modules.
> > >
> > > This patch series is baaed on Luis Chamberlain's patch to generate
> > > modules.builtin.objs, associating built-in modules with their object
> > > files. Using this data, vmlinux.o.map and vmlinux.map can be parsed in
> > > a single pass to generate a modules.buitin.ranges file with offset range
> > > information (relative to the base address of the associated section) for
> > > built-in modules. The file gets installed along with the other
> > > modules.builtin.* files.
> >
> >
> >
> > I still do not want to see modules.builtin.objs.
> >
> >
> > During the vmlinux.o.map parse, every time an object path
> > is encountered, you can open the corresponding .cmd file.
> >
> >
> >
> > Let's say, you have the following in vmlinux.o.map:
> >
> > .text 0x00000000007d4fe0 0x46c8 drivers/i2c/i2c-core-base.o
> >
> >
> >
> > You can check drivers/i2c/.i2c-core-base.o.cmd
> >
> >
> > $ cat drivers/i2c/.i2c-core-base.o.cmd | tr ' ' '\n' | grep KBUILD_MODFILE
> > -DKBUILD_MODFILE='"drivers/i2c/i2c-core"'
> >
> >
> > Now you know this object is part of drivers/i2c/i2c-core
> > (that is, its modname is "i2c-core")
> >
> >
> >
> >
> > Next, you will get the following:
> >
> > .text 0x00000000007dc550 0x13c4 drivers/i2c/i2c-core-acpi.o
> >
> >
> > $ cat drivers/i2c/.i2c-core-acpi.o.cmd | tr ' ' '\n' | grep KBUILD_MODFILE
> > -DKBUILD_MODFILE='"drivers/i2c/i2c-core"'
> >
> >
> > This one is also a part of drivers/i2c/i2c-core
> >
> >
> > You will get the address range of "i2c-core" without changing Makefiles.
>
> Thank you for this suggestion. I have this approach now implemented, making
> use of both KBUILD_MODFILE and KBUILD_MODNAME (both are needed to conclusively
> determine that an object belongs to a module).
>
> However, this is not catching objects that are compiled from assembler source,
> because modfile_flags and modname_flags are not added to the assembler flags,
> and thus KBUILD_MODFILE and KBUILD_MODNAME are not present in the .cmd file
> for those objects.
>
> It would seem that it is harmless to add those flags to assembler flags, so
> would that be an acceptable solution? It definitely would provide consistency
> with non-asm objects. And we already pass modfile and modname flags to the
> non-asm builds for objects that most certainly do not belong in modules amnyway,
> e.g.
>
> $ cat arch/x86/boot/.cmdline.o.cmd| tr ' ' '\n' | grep -- -DKBUILD_MOD
> -DKBUILD_MODFILE='"arch/x86/boot/cmdline"'
> -DKBUILD_MODNAME='"cmdline"'
I am fine with passing these to *.S files,
as the -D is a preprocessor option.
--
Best Regards
Masahiro Yamada
prev parent reply other threads:[~2024-05-16 2:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 22:40 [PATCH v2 0/6] Generate address range data for built-in modules Kris Van Hees
2024-05-11 22:40 ` [PATCH v2 1/6] kbuild: add modules.builtin.objs Kris Van Hees
2024-05-11 22:40 ` [PATCH v2 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option Kris Van Hees
2024-05-14 23:20 ` kernel test robot
2024-05-11 22:40 ` [PATCH v2 3/6] kbuild: generate a linker map for vmlinux.o Kris Van Hees
2024-05-11 22:40 ` [PATCH v2 4/6] module: script to generate offset ranges for builtin modules Kris Van Hees
2024-05-11 22:40 ` [PATCH v2 5/6] kbuild: generate modules.builtin.ranges when linking the kernel Kris Van Hees
2024-05-13 5:19 ` Masahiro Yamada
2024-05-11 22:40 ` [PATCH v2 6/6] module: add install target for modules.builtin.ranges Kris Van Hees
2024-05-13 5:22 ` Masahiro Yamada
2024-05-13 11:38 ` Masahiro Yamada
2024-05-13 4:43 ` [PATCH v2 0/6] Generate address range data for built-in modules Masahiro Yamada
2024-05-15 16:50 ` Kris Van Hees
2024-05-16 2:56 ` Masahiro Yamada [this message]
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='CAK7LNARRzGt8EWhRcXnj=2G7E1KOq4E-PGUX53wBoCXAsmSr_g@mail.gmail.com' \
--to=masahiroy@kernel.org \
--cc=elena.zannoni@oracle.com \
--cc=kris.van.hees@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=mcgrof@kernel.org \
--cc=mhiramat@kernel.org \
--cc=ndesaulniers@google.com \
--cc=olsajiri@gmail.com \
--cc=rostedt@goodmis.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).