On Fri, 8 Dec 2023 00:07:48 -0500 Kris Van Hees <[email protected]> wrote:
> The CONFIG_BUILTIN_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 <[email protected]> > Reviewed-by: Nick Alcock <[email protected]> > Reviewed-by: Alan Maguire <[email protected]> > --- > kernel/module/Kconfig | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig > index 33a2e991f608..0798439b11ac 100644 > --- a/kernel/module/Kconfig > +++ b/kernel/module/Kconfig > @@ -389,4 +389,21 @@ config MODULES_TREE_LOOKUP > def_bool y > depends on PERF_EVENTS || TRACING || CFI_CLANG > > +config BUILTIN_RANGES BUILTIN_MODULE_RANGES ? BTW, even if CONFIG_MODULES=n, we can embed the kernel module code. So should this visible if the CONFIG_MODULES=n ? Thank you, > + bool "Generate address range information for builtin modules" > + depends on 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. > + > endif # MODULES > -- > 2.42.0 > -- Masami Hiramatsu (Google) <[email protected]>
