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 <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
---
 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
+	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

On Fri,  8 Dec 2023 00:07:48 -0500
Kris Van Hees <kris.van.hees@oracle.com> 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 <kris.van.hees@oracle.com>
> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  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) <mhiramat@kernel.org>

On Sat, Dec 09, 2023 at 07:59:17AM +0900, Masami Hiramatsu wrote:
> On Fri,  8 Dec 2023 00:07:48 -0500
> Kris Van Hees <kris.van.hees@oracle.com> 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 <kris.van.hees@oracle.com>
> > Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
> > Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
> > ---
> >  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 ?

Ah yes, thank you.  Will fix in v2.

> BTW, even if CONFIG_MODULES=n, we can embed the kernel module code.
> So should this visible if the CONFIG_MODULES=n ?

That is a very good point.  And in that case, the ranges information should
still be produced when this option is set.  I will move the option to a more
appropriate location, not depending on CONFIG_MODULES.

> Thank you,

Thank you for your feedback!

> > +	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) <mhiramat@kernel.org>