On Fri, May 17, 2024 at 1:30 PM Kris Van Hees <kris.van.h...@oracle.com> wrote: > > The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data > is generated for kernel modules that are built into the kernel image. > > 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> > --- > Changes since v2: > - Add explicit dependency on FTRACE for CONFIG_BUILTIN_MODULE_RANGES > --- > kernel/trace/Kconfig | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index 47345bf1d4a9f..d0c82b4b3a61e 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -188,6 +188,24 @@ menuconfig FTRACE > > if FTRACE > > +config BUILTIN_MODULE_RANGES > + bool "Generate address range information for builtin modules" > + depends on FTRACE
This 'depends on' is redundant because this config is already located between 'if FTRACE' and 'endif'. I believe 2/6 thru 5/6 should be squashed into one commit. Adding only the config option does not make much sense. > + select VMLINUX_MAP > + help > + When modules are built into the kernel, there will be no module name > + associated with its symbols in /proc/kallsyms. Tracers may want to > + identify symbols by module name and symbol name regardless of > whether > + the module is configured as loadable or not. > + > + This option generates modules.builtin.ranges in the build tree with > + offset ranges (per ELF section) for the module(s) they belong to. > + It also records an anchor symbol to determine the load address of > the > + section. > + > + It is fully compatible with CONFIG_RANDOMIZE_BASE and similar late- > + address-modification options. > + > config BOOTTIME_TRACING > bool "Boot-time Tracing support" > depends on TRACING > -- > 2.43.0 > -- Best Regards Masahiro Yamada
