[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNAR5+WifCJh_OfE14XNatVEGisS2rOu-dJejhD3skXVnUQ@mail.gmail.com>
Date: Tue, 3 Sep 2024 01:00:15 +0900
From: Masahiro Yamada <masahiroy@...nel.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,
Nick Alcock <nick.alcock@...cle.com>, Alan Maguire <alan.maguire@...cle.com>,
Steven Rostedt <rostedt@...dmis.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 v9 2/4] kbuild: generate offset range data for builtin modules
On Mon, Sep 2, 2024 at 11:06 PM Kris Van Hees <kris.van.hees@...cle.com> wrote:
>
> On Mon, Sep 02, 2024 at 04:26:48PM +0900, Masahiro Yamada wrote:
> > On Sat, Aug 24, 2024 at 12:38???PM Kris Van Hees <kris.van.hees@...cle.com> wrote:
> > >
> > > Create file module.builtin.ranges that can be used to find where
> > > built-in modules are located by their addresses. This will be useful for
> > > tracing tools to find what functions are for various built-in modules.
> > >
> > > The offset range data for builtin modules is generated using:
> > > - modules.builtin: associates object files with module names
> > > - vmlinux.map: provides load order of sections and offset of first member
> > > per section
> > > - vmlinux.o.map: provides offset of object file content per section
> > > - .*.cmd: build cmd file with KBUILD_MODFILE
> > >
> > > The generated data will look like:
> > >
> > > .text 00000000-00000000 = _text
> > > .text 0000baf0-0000cb10 amd_uncore
> > > .text 0009bd10-0009c8e0 iosf_mbi
> > > ...
> > > .text 00b9f080-00ba011a intel_skl_int3472_discrete
> > > .text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
> > > .text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
> > > ...
> > > .data 00000000-00000000 = _sdata
> > > .data 0000f020-0000f680 amd_uncore
> > >
> > > For each ELF section, it lists the offset of the first symbol. This can
> > > be used to determine the base address of the section at runtime.
> > >
> > > Next, it lists (in strict ascending order) offset ranges in that section
> > > that cover the symbols of one or more builtin modules. Multiple ranges
> > > can apply to a single module, and ranges can be shared between modules.
> > >
> > > The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
> > > is generated for kernel modules that are built into the kernel image.
> > >
> > > How it works:
> > >
> > > 1. The modules.builtin file is parsed to obtain a list of built-in
> > > module names and their associated object names (the .ko file that
> > > the module would be in if it were a loadable module, hereafter
> > > referred to as <kmodfile>). This object name can be used to
> > > identify objects in the kernel compile because any C or assembler
> > > code that ends up into a built-in module will have the option
> > > -DKBUILD_MODFILE=<kmodfile> present in its build command, and those
> > > can be found in the .<obj>.cmd file in the kernel build tree.
> > >
> > > If an object is part of multiple modules, they will all be listed
> > > in the KBUILD_MODFILE option argument.
> > >
> > > This allows us to conclusively determine whether an object in the
> > > kernel build belong to any modules, and which.
> > >
> > > 2. The vmlinux.map is parsed next to determine the base address of each
> > > top level section so that all addresses into the section can be
> > > turned into offsets. This makes it possible to handle sections
> > > getting loaded at different addresses at system boot.
> > >
> > > We also determine an 'anchor' symbol at the beginning of each
> > > section to make it possible to calculate the true base address of
> > > a section at runtime (i.e. symbol address - symbol offset).
> > >
> > > We collect start addresses of sections that are included in the top
> > > level section. This is used when vmlinux is linked using vmlinux.o,
> > > because in that case, we need to look at the vmlinux.o linker map to
> > > know what object a symbol is found in.
> > >
> > > And finally, we process each symbol that is listed in vmlinux.map
> > > (or vmlinux.o.map) based on the following structure:
> > >
> > > vmlinux linked from vmlinux.a:
> > >
> > > vmlinux.map:
> > > <top level section>
> > > <included section> -- might be same as top level section)
> > > <object> -- built-in association known
> > > <symbol> -- belongs to module(s) object belongs to
> > > ...
> > >
> > > vmlinux linked from vmlinux.o:
> > >
> > > vmlinux.map:
> > > <top level section>
> > > <included section> -- might be same as top level section)
> > > vmlinux.o -- need to use vmlinux.o.map
> > > <symbol> -- ignored
> > > ...
> > >
> > > vmlinux.o.map:
> > > <section>
> > > <object> -- built-in association known
> > > <symbol> -- belongs to module(s) object belongs to
> > > ...
> > >
> > > 3. As sections, objects, and symbols are processed, offset ranges are
> > > constructed in a straight-forward way:
> > >
> > > - If the symbol belongs to one or more built-in modules:
> > > - If we were working on the same module(s), extend the range
> > > to include this object
> > > - If we were working on another module(s), close that range,
> > > and start the new one
> > > - If the symbol does not belong to any built-in modules:
> > > - If we were working on a module(s) range, close that range
> > >
> > > Signed-off-by: Kris Van Hees <kris.van.hees@...cle.com>
> > > Reviewed-by: Nick Alcock <nick.alcock@...cle.com>
> > > Reviewed-by: Alan Maguire <alan.maguire@...cle.com>
> > > Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>
> > > ---
> > > Changes since v8:
> > > - Added support for built-in Rust modules.
> > > - Added optional 4th argument to specify kernel build directory.
> >
> >
> > When is the 4th parameter useful?
> >
> > The map file knows all object paths.
> >
> > The object file and its .*.cmd file exist in the same directory.
> >
> > I did not find a use-case where the kdir prefix plays a role.
> >
> > Did I miss something?
>
> I added it as an optional parameter in case there is a reason to run the
> script manually and the kernel was built using O=<objdir>.
I do not think it is so useful.
You would end up with adding the build path to all four parameters.
$ scripts/generate_builtin_ranges.awk \
/path/to/build/dir/modules.builtin \
/path/to/build/dir/vmlinux.map \
/path/to/build/dir/vmlinux.o.map \
/path/to/build/dir
If you need to manual execution,
I'd suggest the following:
$ cd /path/to/build/dir
$ source/scripts/generate_builtin_ranges.awk \
modules.builtin vmlinux.map vmlinux.o.map
(Please note that the build directory has
a symbolic link to the source directory)
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists