On Tue, Feb 08, 2022 at 06:43:03PM +0000, Nick Alcock wrote: > The kallmodsyms patch series was originally posted in Nov 2019, and the thread > (https://lore.kernel.org/linux-kbuild/20191114223036.9359-1-eugene.loh@xxxxxxxxxx/t/#u) > shows review comments, questions, and feedback from interested parties. > > All review comments have been satisfied, as far as I know: in particular > Yamada's note about translation units that are shared between built-in modules > is satisfied with a better representation which is also much, much smaller. > > A kernel tree containing this series alone, atop -rc3: > https://github.com/oracle/dtrace-linux-kernel kallmodsyms/5.17-rc3 > > Trees for trying this out, if you want to try this series in conjunction > with its major current user: > > userspace tree for the dtrace tool itself: > https://github.com/oracle/dtrace-utils.git, dev branch > kernel tree comprising this series and a few other patches needed by > dtrace: > https://github.com/oracle/dtrace-linux-kernel, v2/5.17-rc2 branch > > (See the README.md in the latter for dtrace build instructions. Note the need for a > reasonably recent binutils, a trunk GCC, and a cross-bpf toolchain.) > > > /proc/kallsyms is very useful for tracers and other tools that need to > map kernel symbols to addresses. > > It would be useful if there were a mapping between kernel symbol and module > name that only changed when the kernel source code is changed. This mapping > should not change simply because a module becomes built into the kernel, so > that it's not broken by changes in user configuration. (DTrace for Linux > already uses the approach in this patch for this purpose.) > > In brief we do this by mapping from address ranges to object files (with > assistance from the linker map file), then mapping from object files to > potential kernel modules. Because the number of object files is much smaller > than the number of symbols, this is a fairly efficient representation, even with > a bit of extra complexity to allow object files to be in more than one module at > once. > > The size impact of all of this is minimal: in one of my tests, vmlinux grew by > 0.17% (10824 bytes), and the compressed vmlinux only grew by 0.08% (7552 bytes): > though this is very configuration-dependent, it seems likely to scale roughly > with the kernel as a whole. > > This is all controlled by a new config parameter CONFIG_KALLMODSYMS, which when > set results in output in /proc/kallmodsyms that looks like this: > > ffffffff8b013d20 409 t pt_buffer_setup_aux > ffffffff8b014130 11f T intel_pt_interrupt > ffffffff8b014250 2d T cpu_emergency_stop_pt > ffffffff8b014280 13a t rapl_pmu_event_init [intel_rapl_perf] > ffffffff8b0143c0 bb t rapl_event_update [intel_rapl_perf] > ffffffff8b014480 10 t rapl_pmu_event_read [intel_rapl_perf] > ffffffff8b014490 a3 t rapl_cpu_offline [intel_rapl_perf] > ffffffff8b014540 24 t __rapl_event_show [intel_rapl_perf] > ffffffff8b014570 f2 t rapl_pmu_event_stop [intel_rapl_perf] hi, I tried this version and can't see the symbols size [root@qemu jolsa]# cat /proc/kallmodsyms | grep ksys_ | head -5 ffffffff81094720 T ksys_ioperm ffffffff81141110 T ksys_unshare ffffffff81160410 T ksys_setsid ffffffff811c64b0 T ksys_sync_helper ffffffff813213c0 T ksys_fadvise64_64 I have CONFIG_KALLMODSYMS=y, but I haven't checked if I need anything else jirka
