Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Mon, Jan 1, 2024 at 8:11 PM Alessandro Carminati wrote: > > Hello, > > > > Il giorno dom 31 dic 2023 alle ore 06:35 Masahiro Yamada > ha scritto: > > > > On Tue, Dec 5, 2023 at 6:48 AM Alessandro Carminati (Red Hat) > > wrote: > > > > > > In the kernel environment, situations frequently arise where identical > > > names are shared among symbols within both the core image and modules. > > > While this doesn't pose issues for the kernel's binary itself, it > > > complicates trace or probe operations using tools like kprobe. > > > > > > This patch introduces "kas_alias" to address this challenge. > > > > > > During the kernel's build process, just before linking the vmlinux > > > image in the "scripts/link-vmlinux.sh", symbol name frequencies are > > > collected. > > > This collection includes both the core kernel components and modules. > > > Subsequently, within the same action, the nm data relative to vmlinux > > > is modified by adding aliases based on the comprehensive symbol > > > information gathered. > > > > > > The collection process occurs in two phases: > > > > > > 1. First phase: Executed during the linking of vmlinux, "kas_alias" scans > > >all symbols provided by the 'nm' data against the vmlinux core image > > >and all objects used for module linkage. This phase requires all > > >modules objects to be produced at this stage, thereby adding a vmlinux > > >dependency for linking modules in 'scripts/Makefile.modfinal'. > > > > > > 2. Second phase: In a subsequent run in the same build, "kas_alias" > > >processes module objects and injects aliases into the objects' symbol > > >tables where necessary. This operation is done by modifying > > >'scripts/Makefile.modfinal' to include an action for each processed > > >module. > > > > > > Example: > > > > > > Consider the symbol "device_show", you can expect an output like the > > > following: > > > > > > ~ # cat /proc/kallsyms | grep " name_show" > > > caa2bb4f01c8 t name_show > > > caa2bb4f01c8 t name_show@kernel_irq_irqdesc_c_264 > > > caa2bb9c1a30 t name_show > > > caa2bb9c1a30 t name_show@drivers_pnp_card_c_186 > > > caa2bbac4754 t name_show > > > caa2bbac4754 t name_show@drivers_regulator_core_c_678 > > > caa2bbba4900 t name_show > > > caa2bbba4900 t name_show@drivers_base_power_wakeup_stats_c_93 > > > caa2bbec4038 t name_show > > > caa2bbec4038 t name_show@drivers_rtc_sysfs_c_26 > > > caa2bbecc920 t name_show > > > caa2bbecc920 t name_show@drivers_i2c_i2c_core_base_c_660 > > > caa2bbed3840 t name_show > > > caa2bbed3840 t name_show@drivers_i2c_i2c_dev_c_100 > > > caa2bbef7210 t name_show > > > caa2bbef7210 t name_show@drivers_pps_sysfs_c_66 > > > caa2bbf03328 t name_show > > > caa2bbf03328 t name_show@drivers_hwmon_hwmon_c_72 > > > caa2bbff6f3c t name_show > > > caa2bbff6f3c t name_show@drivers_remoteproc_remoteproc_sysfs_c_215 > > > caa2bbff8d78 t name_show > > > caa2bbff8d78 t name_show@drivers_rpmsg_rpmsg_core_c_455 > > > caa2bbfff7a4 t name_show > > > caa2bbfff7a4 t name_show@drivers_devfreq_devfreq_c_1395 > > > caa2bc001f60 t name_show > > > caa2bc001f60 t name_show@drivers_extcon_extcon_c_389 > > > caa2bc009890 t name_show > > > caa2bc009890 t name_show@drivers_iio_industrialio_core_c_1396 > > > caa2bc01212c t name_show > > > caa2bc01212c t name_show@drivers_iio_industrialio_trigger_c_51 > > > caa2bc025e2c t name_show > > > caa2bc025e2c t name_show@drivers_fpga_fpga_mgr_c_618 > > > caa2a052102c t name_show[hello] > > > caa2a052102c t name_show@hello_hello_c_8[hello] > > > caa2a051955c t name_show[rpmsg_char] > > > caa2a051955c t name_show@drivers_rpmsg_rpmsg_char_c_365 > > > [rpmsg_char] > > > > > > where hello, is a plain helloworld module built OOT. > > > > > > Tested-by: Masami Hiramatsu (Google) > > > Signed-off-by: Alessandro Carminati (Red Hat) > > > > > > > > > --- > > > > > > NOTE1: > > > About the symbols name duplication that happens as consequence of the > > > inclusion compat_binfmt_elf.c does, it is evident that this corner is > > > inherently challenging the addr2line approach. > > > Attempting to conceal this limitation would be counterproductive. > > > > > > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help > > > but report all functions and data declared by that file, coming from > > > binfmt_elf.c. > > > > > > My position is that, rather than producing a more complicated pipeline > > > to handle this corner case, it is better to fix the compat_binfmt_elf.c > > > anomaly. > > > > > > This patch does not deal with the two potentially problematic symbols > > > defined by compat_binfmt_elf.c > > > > > > Changes from v1: > > > * Integrated changes requested by Masami to exclude symbols with prefixes > > > "_cfi" and "_pfx". > > > * Introduced a small framework to handle patterns that need to be excluded >
Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hello, Il giorno dom 31 dic 2023 alle ore 06:35 Masahiro Yamada ha scritto: > > On Tue, Dec 5, 2023 at 6:48 AM Alessandro Carminati (Red Hat) > wrote: > > > > In the kernel environment, situations frequently arise where identical > > names are shared among symbols within both the core image and modules. > > While this doesn't pose issues for the kernel's binary itself, it > > complicates trace or probe operations using tools like kprobe. > > > > This patch introduces "kas_alias" to address this challenge. > > > > During the kernel's build process, just before linking the vmlinux > > image in the "scripts/link-vmlinux.sh", symbol name frequencies are > > collected. > > This collection includes both the core kernel components and modules. > > Subsequently, within the same action, the nm data relative to vmlinux > > is modified by adding aliases based on the comprehensive symbol > > information gathered. > > > > The collection process occurs in two phases: > > > > 1. First phase: Executed during the linking of vmlinux, "kas_alias" scans > >all symbols provided by the 'nm' data against the vmlinux core image > >and all objects used for module linkage. This phase requires all > >modules objects to be produced at this stage, thereby adding a vmlinux > >dependency for linking modules in 'scripts/Makefile.modfinal'. > > > > 2. Second phase: In a subsequent run in the same build, "kas_alias" > >processes module objects and injects aliases into the objects' symbol > >tables where necessary. This operation is done by modifying > >'scripts/Makefile.modfinal' to include an action for each processed > >module. > > > > Example: > > > > Consider the symbol "device_show", you can expect an output like the > > following: > > > > ~ # cat /proc/kallsyms | grep " name_show" > > caa2bb4f01c8 t name_show > > caa2bb4f01c8 t name_show@kernel_irq_irqdesc_c_264 > > caa2bb9c1a30 t name_show > > caa2bb9c1a30 t name_show@drivers_pnp_card_c_186 > > caa2bbac4754 t name_show > > caa2bbac4754 t name_show@drivers_regulator_core_c_678 > > caa2bbba4900 t name_show > > caa2bbba4900 t name_show@drivers_base_power_wakeup_stats_c_93 > > caa2bbec4038 t name_show > > caa2bbec4038 t name_show@drivers_rtc_sysfs_c_26 > > caa2bbecc920 t name_show > > caa2bbecc920 t name_show@drivers_i2c_i2c_core_base_c_660 > > caa2bbed3840 t name_show > > caa2bbed3840 t name_show@drivers_i2c_i2c_dev_c_100 > > caa2bbef7210 t name_show > > caa2bbef7210 t name_show@drivers_pps_sysfs_c_66 > > caa2bbf03328 t name_show > > caa2bbf03328 t name_show@drivers_hwmon_hwmon_c_72 > > caa2bbff6f3c t name_show > > caa2bbff6f3c t name_show@drivers_remoteproc_remoteproc_sysfs_c_215 > > caa2bbff8d78 t name_show > > caa2bbff8d78 t name_show@drivers_rpmsg_rpmsg_core_c_455 > > caa2bbfff7a4 t name_show > > caa2bbfff7a4 t name_show@drivers_devfreq_devfreq_c_1395 > > caa2bc001f60 t name_show > > caa2bc001f60 t name_show@drivers_extcon_extcon_c_389 > > caa2bc009890 t name_show > > caa2bc009890 t name_show@drivers_iio_industrialio_core_c_1396 > > caa2bc01212c t name_show > > caa2bc01212c t name_show@drivers_iio_industrialio_trigger_c_51 > > caa2bc025e2c t name_show > > caa2bc025e2c t name_show@drivers_fpga_fpga_mgr_c_618 > > caa2a052102c t name_show[hello] > > caa2a052102c t name_show@hello_hello_c_8[hello] > > caa2a051955c t name_show[rpmsg_char] > > caa2a051955c t name_show@drivers_rpmsg_rpmsg_char_c_365 [rpmsg_char] > > > > where hello, is a plain helloworld module built OOT. > > > > Tested-by: Masami Hiramatsu (Google) > > Signed-off-by: Alessandro Carminati (Red Hat) > > > > > > --- > > > > NOTE1: > > About the symbols name duplication that happens as consequence of the > > inclusion compat_binfmt_elf.c does, it is evident that this corner is > > inherently challenging the addr2line approach. > > Attempting to conceal this limitation would be counterproductive. > > > > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help > > but report all functions and data declared by that file, coming from > > binfmt_elf.c. > > > > My position is that, rather than producing a more complicated pipeline > > to handle this corner case, it is better to fix the compat_binfmt_elf.c > > anomaly. > > > > This patch does not deal with the two potentially problematic symbols > > defined by compat_binfmt_elf.c > > > > Changes from v1: > > * Integrated changes requested by Masami to exclude symbols with prefixes > > "_cfi" and "_pfx". > > * Introduced a small framework to handle patterns that need to be excluded > > from the alias production. > > * Excluded other symbols using the framework. > > * Introduced the ability to discriminate between text and data symbols. > > * Added two new config symbols in this version: > > CONFIG_KALLSYMS_ALIAS_DATA, which allows data for data, and > >
Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Tue, Dec 5, 2023 at 6:48 AM Alessandro Carminati (Red Hat) wrote: > > In the kernel environment, situations frequently arise where identical > names are shared among symbols within both the core image and modules. > While this doesn't pose issues for the kernel's binary itself, it > complicates trace or probe operations using tools like kprobe. > > This patch introduces "kas_alias" to address this challenge. > > During the kernel's build process, just before linking the vmlinux > image in the "scripts/link-vmlinux.sh", symbol name frequencies are > collected. > This collection includes both the core kernel components and modules. > Subsequently, within the same action, the nm data relative to vmlinux > is modified by adding aliases based on the comprehensive symbol > information gathered. > > The collection process occurs in two phases: > > 1. First phase: Executed during the linking of vmlinux, "kas_alias" scans >all symbols provided by the 'nm' data against the vmlinux core image >and all objects used for module linkage. This phase requires all >modules objects to be produced at this stage, thereby adding a vmlinux >dependency for linking modules in 'scripts/Makefile.modfinal'. > > 2. Second phase: In a subsequent run in the same build, "kas_alias" >processes module objects and injects aliases into the objects' symbol >tables where necessary. This operation is done by modifying >'scripts/Makefile.modfinal' to include an action for each processed >module. > > Example: > > Consider the symbol "device_show", you can expect an output like the > following: > > ~ # cat /proc/kallsyms | grep " name_show" > caa2bb4f01c8 t name_show > caa2bb4f01c8 t name_show@kernel_irq_irqdesc_c_264 > caa2bb9c1a30 t name_show > caa2bb9c1a30 t name_show@drivers_pnp_card_c_186 > caa2bbac4754 t name_show > caa2bbac4754 t name_show@drivers_regulator_core_c_678 > caa2bbba4900 t name_show > caa2bbba4900 t name_show@drivers_base_power_wakeup_stats_c_93 > caa2bbec4038 t name_show > caa2bbec4038 t name_show@drivers_rtc_sysfs_c_26 > caa2bbecc920 t name_show > caa2bbecc920 t name_show@drivers_i2c_i2c_core_base_c_660 > caa2bbed3840 t name_show > caa2bbed3840 t name_show@drivers_i2c_i2c_dev_c_100 > caa2bbef7210 t name_show > caa2bbef7210 t name_show@drivers_pps_sysfs_c_66 > caa2bbf03328 t name_show > caa2bbf03328 t name_show@drivers_hwmon_hwmon_c_72 > caa2bbff6f3c t name_show > caa2bbff6f3c t name_show@drivers_remoteproc_remoteproc_sysfs_c_215 > caa2bbff8d78 t name_show > caa2bbff8d78 t name_show@drivers_rpmsg_rpmsg_core_c_455 > caa2bbfff7a4 t name_show > caa2bbfff7a4 t name_show@drivers_devfreq_devfreq_c_1395 > caa2bc001f60 t name_show > caa2bc001f60 t name_show@drivers_extcon_extcon_c_389 > caa2bc009890 t name_show > caa2bc009890 t name_show@drivers_iio_industrialio_core_c_1396 > caa2bc01212c t name_show > caa2bc01212c t name_show@drivers_iio_industrialio_trigger_c_51 > caa2bc025e2c t name_show > caa2bc025e2c t name_show@drivers_fpga_fpga_mgr_c_618 > caa2a052102c t name_show[hello] > caa2a052102c t name_show@hello_hello_c_8[hello] > caa2a051955c t name_show[rpmsg_char] > caa2a051955c t name_show@drivers_rpmsg_rpmsg_char_c_365 [rpmsg_char] > > where hello, is a plain helloworld module built OOT. > > Tested-by: Masami Hiramatsu (Google) > Signed-off-by: Alessandro Carminati (Red Hat) > > --- > > NOTE1: > About the symbols name duplication that happens as consequence of the > inclusion compat_binfmt_elf.c does, it is evident that this corner is > inherently challenging the addr2line approach. > Attempting to conceal this limitation would be counterproductive. > > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help > but report all functions and data declared by that file, coming from > binfmt_elf.c. > > My position is that, rather than producing a more complicated pipeline > to handle this corner case, it is better to fix the compat_binfmt_elf.c > anomaly. > > This patch does not deal with the two potentially problematic symbols > defined by compat_binfmt_elf.c > > Changes from v1: > * Integrated changes requested by Masami to exclude symbols with prefixes > "_cfi" and "_pfx". > * Introduced a small framework to handle patterns that need to be excluded > from the alias production. > * Excluded other symbols using the framework. > * Introduced the ability to discriminate between text and data symbols. > * Added two new config symbols in this version: > CONFIG_KALLSYMS_ALIAS_DATA, which allows data for data, and > CONFIG_KALLSYMS_ALIAS_DATA_ALL, which excludes all filters and provides > an alias for each duplicated symbol. > > https://lore.kernel.org/all/20230711151925.1092080-1-alessandro.carmin...@gmail.com/ > > Changes from v2: > * Alias tags are created by querying DWARF information from the vmlinux. > * The
Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hello Francis, Thanks for the review. Il giorno gio 21 dic 2023 alle ore 18:23 Francis Laniel ha scritto: > > Hi! > > > Le lundi 4 décembre 2023, 22:46:35 CET Alessandro Carminati (Red Hat) a > écrit : > > In the kernel environment, situations frequently arise where identical > > names are shared among symbols within both the core image and modules. > > While this doesn't pose issues for the kernel's binary itself, it > > complicates trace or probe operations using tools like kprobe. > > > > This patch introduces "kas_alias" to address this challenge. > > > > During the kernel's build process, just before linking the vmlinux > > image in the "scripts/link-vmlinux.sh", symbol name frequencies are > > collected. > > This collection includes both the core kernel components and modules. > > Subsequently, within the same action, the nm data relative to vmlinux > > is modified by adding aliases based on the comprehensive symbol > > information gathered. > > > > The collection process occurs in two phases: > > > > 1. First phase: Executed during the linking of vmlinux, "kas_alias" scans > >all symbols provided by the 'nm' data against the vmlinux core image > >and all objects used for module linkage. This phase requires all > >modules objects to be produced at this stage, thereby adding a vmlinux > >dependency for linking modules in 'scripts/Makefile.modfinal'. > > > > 2. Second phase: In a subsequent run in the same build, "kas_alias" > >processes module objects and injects aliases into the objects' symbol > >tables where necessary. This operation is done by modifying > >'scripts/Makefile.modfinal' to include an action for each processed > >module. > > > > Example: > > > > Consider the symbol "device_show", you can expect an output like the > > following: > > > > ~ # cat /proc/kallsyms | grep " name_show" > > caa2bb4f01c8 t name_show > > caa2bb4f01c8 t name_show@kernel_irq_irqdesc_c_264 > > caa2bb9c1a30 t name_show > > caa2bb9c1a30 t name_show@drivers_pnp_card_c_186 > > caa2bbac4754 t name_show > > caa2bbac4754 t name_show@drivers_regulator_core_c_678 > > caa2bbba4900 t name_show > > caa2bbba4900 t name_show@drivers_base_power_wakeup_stats_c_93 > > caa2bbec4038 t name_show > > caa2bbec4038 t name_show@drivers_rtc_sysfs_c_26 > > caa2bbecc920 t name_show > > caa2bbecc920 t name_show@drivers_i2c_i2c_core_base_c_660 > > caa2bbed3840 t name_show > > caa2bbed3840 t name_show@drivers_i2c_i2c_dev_c_100 > > caa2bbef7210 t name_show > > caa2bbef7210 t name_show@drivers_pps_sysfs_c_66 > > caa2bbf03328 t name_show > > caa2bbf03328 t name_show@drivers_hwmon_hwmon_c_72 > > caa2bbff6f3c t name_show > > caa2bbff6f3c t name_show@drivers_remoteproc_remoteproc_sysfs_c_215 > > caa2bbff8d78 t name_show > > caa2bbff8d78 t name_show@drivers_rpmsg_rpmsg_core_c_455 > > caa2bbfff7a4 t name_show > > caa2bbfff7a4 t name_show@drivers_devfreq_devfreq_c_1395 > > caa2bc001f60 t name_show > > caa2bc001f60 t name_show@drivers_extcon_extcon_c_389 > > caa2bc009890 t name_show > > caa2bc009890 t name_show@drivers_iio_industrialio_core_c_1396 > > caa2bc01212c t name_show > > caa2bc01212c t name_show@drivers_iio_industrialio_trigger_c_51 > > caa2bc025e2c t name_show > > caa2bc025e2c t name_show@drivers_fpga_fpga_mgr_c_618 > > caa2a052102c t name_show [hello] > > caa2a052102c t name_show@hello_hello_c_8 [hello] > > caa2a051955c t name_show [rpmsg_char] > > caa2a051955c t name_show@drivers_rpmsg_rpmsg_char_c_365 [rpmsg_char] > > > > where hello, is a plain helloworld module built OOT. > > Thank you for sending the v7 and sorry for the delay! > I tested it and it works fine: > root@vm-amd64:~# uname -r > 6.7.0-rc6-00079-g6162f0ee7bcb > root@vm-amd64:~# grep name_show /proc/kallsyms | head -5 > b400f230 t __pfx_pmu_name_show > b400f240 t pmu_name_show > b40fb1d0 t __pfx_name_show > b40fb1e0 t name_show > b40fb1e0 t name_show@kernel_irq_irqdesc_c_264 > > I am curious about the module part, can you please indicate me how you tested > it? Are you referring to the process of building an OOT module and including aliases? If that's the query, the current build now generates an additional file named modules.symbfreq, which contains the frequencies of symbols. Here's an example: ~ # cat modules.symbfreq [...] bcm2835_handle_irq:1 bcm2836_arm_irqchip_handle_irq:1 dw_apb_ictl_handle_irq:1 gic_handle_irq:2 aic_handle_irq:1 [...] To proceed, this file needs to be copied to the root directory of the OOT module, following which the module can undergo the regular build process. If this file is not found during the build, no aliases will be added to that particular module. > > I found some nits in the code but nothing critical: I experimented with several approaches to tackle this problem before discovering one that proved satisfactory.
Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hi! Le lundi 4 décembre 2023, 22:46:35 CET Alessandro Carminati (Red Hat) a écrit : > In the kernel environment, situations frequently arise where identical > names are shared among symbols within both the core image and modules. > While this doesn't pose issues for the kernel's binary itself, it > complicates trace or probe operations using tools like kprobe. > > This patch introduces "kas_alias" to address this challenge. > > During the kernel's build process, just before linking the vmlinux > image in the "scripts/link-vmlinux.sh", symbol name frequencies are > collected. > This collection includes both the core kernel components and modules. > Subsequently, within the same action, the nm data relative to vmlinux > is modified by adding aliases based on the comprehensive symbol > information gathered. > > The collection process occurs in two phases: > > 1. First phase: Executed during the linking of vmlinux, "kas_alias" scans >all symbols provided by the 'nm' data against the vmlinux core image >and all objects used for module linkage. This phase requires all >modules objects to be produced at this stage, thereby adding a vmlinux >dependency for linking modules in 'scripts/Makefile.modfinal'. > > 2. Second phase: In a subsequent run in the same build, "kas_alias" >processes module objects and injects aliases into the objects' symbol >tables where necessary. This operation is done by modifying >'scripts/Makefile.modfinal' to include an action for each processed >module. > > Example: > > Consider the symbol "device_show", you can expect an output like the > following: > > ~ # cat /proc/kallsyms | grep " name_show" > caa2bb4f01c8 t name_show > caa2bb4f01c8 t name_show@kernel_irq_irqdesc_c_264 > caa2bb9c1a30 t name_show > caa2bb9c1a30 t name_show@drivers_pnp_card_c_186 > caa2bbac4754 t name_show > caa2bbac4754 t name_show@drivers_regulator_core_c_678 > caa2bbba4900 t name_show > caa2bbba4900 t name_show@drivers_base_power_wakeup_stats_c_93 > caa2bbec4038 t name_show > caa2bbec4038 t name_show@drivers_rtc_sysfs_c_26 > caa2bbecc920 t name_show > caa2bbecc920 t name_show@drivers_i2c_i2c_core_base_c_660 > caa2bbed3840 t name_show > caa2bbed3840 t name_show@drivers_i2c_i2c_dev_c_100 > caa2bbef7210 t name_show > caa2bbef7210 t name_show@drivers_pps_sysfs_c_66 > caa2bbf03328 t name_show > caa2bbf03328 t name_show@drivers_hwmon_hwmon_c_72 > caa2bbff6f3c t name_show > caa2bbff6f3c t name_show@drivers_remoteproc_remoteproc_sysfs_c_215 > caa2bbff8d78 t name_show > caa2bbff8d78 t name_show@drivers_rpmsg_rpmsg_core_c_455 > caa2bbfff7a4 t name_show > caa2bbfff7a4 t name_show@drivers_devfreq_devfreq_c_1395 > caa2bc001f60 t name_show > caa2bc001f60 t name_show@drivers_extcon_extcon_c_389 > caa2bc009890 t name_show > caa2bc009890 t name_show@drivers_iio_industrialio_core_c_1396 > caa2bc01212c t name_show > caa2bc01212c t name_show@drivers_iio_industrialio_trigger_c_51 > caa2bc025e2c t name_show > caa2bc025e2c t name_show@drivers_fpga_fpga_mgr_c_618 > caa2a052102c t name_show [hello] > caa2a052102c t name_show@hello_hello_c_8 [hello] > caa2a051955c t name_show [rpmsg_char] > caa2a051955c t name_show@drivers_rpmsg_rpmsg_char_c_365 [rpmsg_char] > > where hello, is a plain helloworld module built OOT. Thank you for sending the v7 and sorry for the delay! I tested it and it works fine: root@vm-amd64:~# uname -r 6.7.0-rc6-00079-g6162f0ee7bcb root@vm-amd64:~# grep name_show /proc/kallsyms | head -5 b400f230 t __pfx_pmu_name_show b400f240 t pmu_name_show b40fb1d0 t __pfx_name_show b40fb1e0 t name_show b40fb1e0 t name_show@kernel_irq_irqdesc_c_264 I am curious about the module part, can you please indicate me how you tested it? I found some nits in the code but nothing critical: > Tested-by: Masami Hiramatsu (Google) > Signed-off-by: Alessandro Carminati (Red Hat) > > > --- > > NOTE1: > About the symbols name duplication that happens as consequence of the > inclusion compat_binfmt_elf.c does, it is evident that this corner is > inherently challenging the addr2line approach. > Attempting to conceal this limitation would be counterproductive. > > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help > but report all functions and data declared by that file, coming from > binfmt_elf.c. > > My position is that, rather than producing a more complicated pipeline > to handle this corner case, it is better to fix the compat_binfmt_elf.c > anomaly. > > This patch does not deal with the two potentially problematic symbols > defined by compat_binfmt_elf.c > > Changes from v1: > * Integrated changes requested by Masami to exclude symbols with prefixes > "_cfi" and "_pfx". > * Introduced a small framework to handle patterns that need to be excluded > from the alias production. >
Re: [PATCH v7] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
gentle ping Il giorno lun 4 dic 2023 alle ore 22:47 Alessandro Carminati (Red Hat) ha scritto: > > In the kernel environment, situations frequently arise where identical > names are shared among symbols within both the core image and modules. > While this doesn't pose issues for the kernel's binary itself, it > complicates trace or probe operations using tools like kprobe. > > This patch introduces "kas_alias" to address this challenge. > > During the kernel's build process, just before linking the vmlinux > image in the "scripts/link-vmlinux.sh", symbol name frequencies are > collected. > This collection includes both the core kernel components and modules. > Subsequently, within the same action, the nm data relative to vmlinux > is modified by adding aliases based on the comprehensive symbol > information gathered. > > The collection process occurs in two phases: > > 1. First phase: Executed during the linking of vmlinux, "kas_alias" scans >all symbols provided by the 'nm' data against the vmlinux core image >and all objects used for module linkage. This phase requires all >modules objects to be produced at this stage, thereby adding a vmlinux >dependency for linking modules in 'scripts/Makefile.modfinal'. > > 2. Second phase: In a subsequent run in the same build, "kas_alias" >processes module objects and injects aliases into the objects' symbol >tables where necessary. This operation is done by modifying >'scripts/Makefile.modfinal' to include an action for each processed >module. > > Example: > > Consider the symbol "device_show", you can expect an output like the > following: > > ~ # cat /proc/kallsyms | grep " name_show" > caa2bb4f01c8 t name_show > caa2bb4f01c8 t name_show@kernel_irq_irqdesc_c_264 > caa2bb9c1a30 t name_show > caa2bb9c1a30 t name_show@drivers_pnp_card_c_186 > caa2bbac4754 t name_show > caa2bbac4754 t name_show@drivers_regulator_core_c_678 > caa2bbba4900 t name_show > caa2bbba4900 t name_show@drivers_base_power_wakeup_stats_c_93 > caa2bbec4038 t name_show > caa2bbec4038 t name_show@drivers_rtc_sysfs_c_26 > caa2bbecc920 t name_show > caa2bbecc920 t name_show@drivers_i2c_i2c_core_base_c_660 > caa2bbed3840 t name_show > caa2bbed3840 t name_show@drivers_i2c_i2c_dev_c_100 > caa2bbef7210 t name_show > caa2bbef7210 t name_show@drivers_pps_sysfs_c_66 > caa2bbf03328 t name_show > caa2bbf03328 t name_show@drivers_hwmon_hwmon_c_72 > caa2bbff6f3c t name_show > caa2bbff6f3c t name_show@drivers_remoteproc_remoteproc_sysfs_c_215 > caa2bbff8d78 t name_show > caa2bbff8d78 t name_show@drivers_rpmsg_rpmsg_core_c_455 > caa2bbfff7a4 t name_show > caa2bbfff7a4 t name_show@drivers_devfreq_devfreq_c_1395 > caa2bc001f60 t name_show > caa2bc001f60 t name_show@drivers_extcon_extcon_c_389 > caa2bc009890 t name_show > caa2bc009890 t name_show@drivers_iio_industrialio_core_c_1396 > caa2bc01212c t name_show > caa2bc01212c t name_show@drivers_iio_industrialio_trigger_c_51 > caa2bc025e2c t name_show > caa2bc025e2c t name_show@drivers_fpga_fpga_mgr_c_618 > caa2a052102c t name_show[hello] > caa2a052102c t name_show@hello_hello_c_8[hello] > caa2a051955c t name_show[rpmsg_char] > caa2a051955c t name_show@drivers_rpmsg_rpmsg_char_c_365 [rpmsg_char] > > where hello, is a plain helloworld module built OOT. > > Tested-by: Masami Hiramatsu (Google) > Signed-off-by: Alessandro Carminati (Red Hat) > > --- > > NOTE1: > About the symbols name duplication that happens as consequence of the > inclusion compat_binfmt_elf.c does, it is evident that this corner is > inherently challenging the addr2line approach. > Attempting to conceal this limitation would be counterproductive. > > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help > but report all functions and data declared by that file, coming from > binfmt_elf.c. > > My position is that, rather than producing a more complicated pipeline > to handle this corner case, it is better to fix the compat_binfmt_elf.c > anomaly. > > This patch does not deal with the two potentially problematic symbols > defined by compat_binfmt_elf.c > > Changes from v1: > * Integrated changes requested by Masami to exclude symbols with prefixes > "_cfi" and "_pfx". > * Introduced a small framework to handle patterns that need to be excluded > from the alias production. > * Excluded other symbols using the framework. > * Introduced the ability to discriminate between text and data symbols. > * Added two new config symbols in this version: > CONFIG_KALLSYMS_ALIAS_DATA, which allows data for data, and > CONFIG_KALLSYMS_ALIAS_DATA_ALL, which excludes all filters and provides > an alias for each duplicated symbol. > > https://lore.kernel.org/all/20230711151925.1092080-1-alessandro.carmin...@gmail.com/ > > Changes from v2: > * Alias tags are created by querying DWARF information from
