| Message ID | 20240906144506.1151789-1-kris.van.hees@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Generate address range data for built-in modules | expand |
Woops, forgot to update the subject line of the 0/4... it *is* v10. Sorry about that.
Hi Kris, On Fri, Sep 06, 2024 at 10:45:01AM -0400, Kris Van Hees wrote: > At build time, create the file modules.builtin.ranges that will hold > address range data of the built-in modules that can be used by tracers. > > Especially for tracing applications, it is convenient to be able to > refer to a symbol using a <module name, symbol name> pair and to be able > to translate an address into a <nodule mname, symbol name> pair. But > that does not work if the module is built into the kernel because the > object files that comprise the built-in module implementation are simply > linked into the kernel image along with all other kernel object files. > > This is especially visible when providing tracing scripts for support > purposes, where the developer of the script targets a particular kernel > version, but does not have control over whether the target system has > a particular module as loadable module or built-in module. When tracing > symbols within a module, referring them by <module name, symbol name> > pairs is both convenient and aids symbol lookup. But that naming will > not work if the module name information is lost if the module is built > into the kernel on the target system. > > Earlier work addressing this loss of information for built-in modules > involved adding module name information to the kallsyms data, but that > required more invasive code in the kernel proper. This work never did > get merged into the kernel tree. > > All that is really needed is knowing whether a given address belongs to > a particular module (or multiple modules if they share an object file). > Or in other words, whether that address falls within an address range > that is associated with one or more modules. > > Objects can be identified as belonging to a particular module (or > modules) based on defines that are passed as flags to their respective > compilation commands. The data found in modules.builtin is used to > determine what modules are built into the kernel proper. Then, > vmlinux.o.map and vmlinux.map can be parsed in a single pass to generate > a modules.buitin.ranges file with offset range information (relative to > the base address of the associated section) for built-in modules. This > file gets installed along with the other modules.builtin.* files. > > The impact on the kernel build is minimal because everything is done > using a single-pass AWK script. The generated data size is minimal as > well, (depending on the exact kernel configuration) usually in the range > of 500-700 lines, with a file size of 20-40KB (if all modules are built > in, the file contains about 8000 lines, with a file size of about 285KB). > > Changes since v9: > - Reverted support for optional 4th arg to generator script. > - Reverted support for optional 6th arg to verifier script. > - Added modules.builtin.ranges ad vmlinux.o.map to CLEAN_FILES. > - Fixed support for sparc64. > - Fixed support for LLVM's lld linker map format. > - Updated error message when .*.cmd.o cannot be read by verifier script. > - Added syntax output for verifier script when not enough args are given. > - Return 1 from verifier if verification fails. v10 looks good to me. I tested x86_64 and arm64 builds with both GNU and LLVM toolchains, and confirmed that built-in Rust modules are handled correctly. The code looks reasonable too. For the series: Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Sami Tolvanen <samitolvanen@google.com> Sami
On Fri, Sep 6, 2024 at 11:45 PM Kris Van Hees <kris.van.hees@oracle.com> wrote: > > At build time, create the file modules.builtin.ranges that will hold > address range data of the built-in modules that can be used by tracers. > > Especially for tracing applications, it is convenient to be able to > refer to a symbol using a <module name, symbol name> pair and to be able > to translate an address into a <nodule mname, symbol name> pair. But > that does not work if the module is built into the kernel because the > object files that comprise the built-in module implementation are simply > linked into the kernel image along with all other kernel object files. > > This is especially visible when providing tracing scripts for support > purposes, where the developer of the script targets a particular kernel > version, but does not have control over whether the target system has > a particular module as loadable module or built-in module. When tracing > symbols within a module, referring them by <module name, symbol name> > pairs is both convenient and aids symbol lookup. But that naming will > not work if the module name information is lost if the module is built > into the kernel on the target system. > > Earlier work addressing this loss of information for built-in modules > involved adding module name information to the kallsyms data, but that > required more invasive code in the kernel proper. This work never did > get merged into the kernel tree. > > All that is really needed is knowing whether a given address belongs to > a particular module (or multiple modules if they share an object file). > Or in other words, whether that address falls within an address range > that is associated with one or more modules. > > Objects can be identified as belonging to a particular module (or > modules) based on defines that are passed as flags to their respective > compilation commands. The data found in modules.builtin is used to > determine what modules are built into the kernel proper. Then, > vmlinux.o.map and vmlinux.map can be parsed in a single pass to generate > a modules.buitin.ranges file with offset range information (relative to > the base address of the associated section) for built-in modules. This > file gets installed along with the other modules.builtin.* files. > > The impact on the kernel build is minimal because everything is done > using a single-pass AWK script. The generated data size is minimal as > well, (depending on the exact kernel configuration) usually in the range > of 500-700 lines, with a file size of 20-40KB (if all modules are built > in, the file contains about 8000 lines, with a file size of about 285KB). > > Changes since v9: > - Reverted support for optional 4th arg to generator script. > - Reverted support for optional 6th arg to verifier script. > - Added modules.builtin.ranges ad vmlinux.o.map to CLEAN_FILES. > - Fixed support for sparc64. > - Fixed support for LLVM's lld linker map format. > - Updated error message when .*.cmd.o cannot be read by verifier script. > - Added syntax output for verifier script when not enough args are given. > - Return 1 from verifier if verification fails. Applied to linux-kbuild. Thanks!