Message-ID: <20240814124548.6e2cce78@gandalf.local.home>
Date: Wed, 14 Aug 2024 12:45:48 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Kris Van Hees <kris.van.hees@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
 linux-modules@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Masahiro
 Yamada <masahiroy@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>, Masami
 Hiramatsu <mhiramat@...nel.org>, Nick Desaulniers
 <ndesaulniers@...gle.com>, Jiri Olsa <olsajiri@...il.com>, Elena Zannoni
 <elena.zannoni@...cle.com>
Subject: Re: [PATCH v5 0/4] Generate address range data for built-in modules

On Mon, 15 Jul 2024 23:10:41 -0400
Kris Van Hees <kris.van.hees@...cle.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.
> 
> Objects can be identified as belonging to a particular module (or
> modules) based on defines that are passed as flags to their respective
> compilation commands.  The data found in modules.builtin is used to
> determine what modules are built into the kernel proper.  Then,
> 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.  This
> file gets installed along with the other modules.builtin.* files.

Hmm, it's hard to parse the above. So the goal is just to make the
modules.builtin.ranges file? If so, that should probably be expressed at
the start, so we know right from the beginning what the result of this is.

  At build time, create the file modules.builtin.ranges that will hold the
  text address of the built-in modules that can be used by tracers.

That just makes it a bit easier to read the rest. I know I'm being a bit
anal on this, but jumping between several different patch series, is making
my head hurt. :-p

But now that I know what you are trying to do, it's now making sense ;-)

-- Steve


> 
> 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 (if all modules are built
> in, the file contains about 8000 lines, with a file size of about 285KB).
> 

Powered by blists - more mailing lists