From: Kris Van Hees <kris.van.hees@oracle.com>
To: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
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: [PATCH v2 0/6] Generate address range data for built-in modules
Date: Sat, 11 May 2024 18:40:29 -0400 [thread overview]
Message-ID: <20240511224035.27775-1-kris.van.hees@oracle.com> (raw)
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.
The impact on the kernel build is minimal because everything is done
using a single-pass AWK script. The generated data size is minimal as
well, (depending on the exact kernel configuration) usually in the range
of 500-700 lines, with a file size of 20-40KB.
Changes since v1:
- Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES
- Moved the config option to the tracers section
- 2nd arg to generate_builtin_ranges.awk should be vmlinux.map
Kris Van Hees (5):
trace: add CONFIG_BUILTIN_MODULE_RANGES option
kbuild: generate a linker map for vmlinux.o
module: script to generate offset ranges for builtin modules
kbuild: generate modules.builtin.ranges when linking the kernel
module: add install target for modules.builtin.ranges
Luis Chamberlain (1):
kbuild: add modules.builtin.objs
.gitignore | 2 +-
Documentation/dontdiff | 2 +-
Documentation/kbuild/kbuild.rst | 5 ++
Makefile | 8 +-
include/linux/module.h | 4 +-
kernel/trace/Kconfig | 17 ++++
scripts/Makefile.lib | 5 +-
scripts/Makefile.modinst | 11 ++-
scripts/Makefile.vmlinux | 17 ++++
scripts/Makefile.vmlinux_o | 18 ++++-
scripts/generate_builtin_ranges.awk | 149 ++++++++++++++++++++++++++++++++++++
11 files changed, 228 insertions(+), 10 deletions(-)
create mode 100755 scripts/generate_builtin_ranges.awk
base-commit: dd5a440a31fae6e459c0d6271dddd62825505361
--
2.42.0
next reply other threads:[~2024-05-11 22:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 22:40 Kris Van Hees [this message]
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
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=20240511224035.27775-1-kris.van.hees@oracle.com \
--to=kris.van.hees@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=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).