On Fri, Sep 6, 2024 at 11:45 PM Kris Van Hees <kris.van.h...@oracle.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.h...@oracle.com> > Reviewed-by: Nick Alcock <nick.alc...@oracle.com> > Reviewed-by: Alan Maguire <alan.magu...@oracle.com> > Reviewed-by: Steven Rostedt (Google) <rost...@goodmis.org> > Tested-by: Sam James <s...@gentoo.org> > ---
If v10 is the final version, I offer to locally squash the following: diff --git a/.gitignore b/.gitignore index c06a3ef6d6c6..625bf59ad845 100644 --- a/.gitignore +++ b/.gitignore @@ -69,6 +69,7 @@ modules.order /Module.markers /modules.builtin /modules.builtin.modinfo +/modules.builtin.ranges /modules.nsdeps # diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 3c399f132e2d..a867aea95c40 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -180,6 +180,7 @@ modpost modules-only.symvers modules.builtin modules.builtin.modinfo +modules.builtin.ranges modules.nsdeps modules.order modversions.h* If Sami reports more errors and you end up with v11, please remember to fold it. -- Best Regards Masahiro Yamada
