Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
>> In any case, as you've pointed out, duplicates can arise from names in code >> that is not intended to be a module. >> Therefore, relying solely on the module name would not fully address the >> problem you initially aimed to solve. > > From my POV: > > The source path and the line number is enough to distinguish duplicate > symbols even in modules. > > The added module name would just add extra complexity into the kernel > and tools parsing and using the alias. The tracing tools would need to > handle the source path and line number anyway for symbols duplicated > within same module/vmlinux. > > Adding module name for builtin modules might be misleading. It won't > be clear which symbols are in vmlinux binary and which are in > real modules. +1 -- Daniel
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Tue, Oct 10, 2023 at 01:33:09PM +0200, Petr Mladek wrote: > On Mon 2023-10-09 15:14:28, Alessandro Carminati wrote: > > Hello Kris, > > > > Thank you for your contribution and for having your thought shared with me. > > > > Allow me to begin this conversation by explaining what came to mind when > > I decided to propose a patch that creates aliases. > > > > The objective was to address a specific problem I was facing while > > minimizing any potential impact on other aspects. > > My initial consideration was the existence of numerous tools, both in the > > kernel and in userspace, that rely on the current kallsyms implementation. > > Both Nick and I shared the concern that making changes to elements upon > > which these tools depend on could have significant consequences. > > > > To the best of my knowledge, Nick's strategy has been to duplicate kallsyms > > with something new - a new, improved kallsyms file. > > > > However, even if Nick's patch were to be accepted, it wouldn't fully meet > > my personal requirements. > > This is because my goal was to utilize kprobe on a symbol that shares its > > name with others. Nick's work wouldn't allow me to do this, and that's why, > > I proposed an alternative. > > > > As a result, my strategy was more modest and focused solely on creating > > aliases for duplicate symbols. > > By adding these aliases, existing tools would remain unaffected, and the > > current system state and ecosystem would be preserved. > > For instance, mechanisms like live patching could continue to use the > > symbol hit count. > > > > On the flip side, introducing these new symbols would enable tracers to > > directly employ the new names without any modifications, and humans could > > easily identify the symbol they are dealing with just by examining the > > name. > > These are the fundamental principles behind my patch - introducing aliases. > > > > Il giorno gio 5 ott 2023 alle ore 18:25 Kris Van Hees > > ha scritto: > > > > > > On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) > > > wrote: > > > > It is not uncommon for drivers or modules related to similar peripherals > > > > to have symbols with the exact same name. > > > > While this is not a problem for the kernel's binary itself, it becomes > > > > an > > > > issue when attempting to trace or probe specific functions using > > > > infrastructure like ftrace or kprobe. > > > > > > > > The tracing subsystem relies on the `nm -n vmlinux` output, which > > > > provides > > > > symbol information from the kernel's ELF binary. However, when multiple > > > > symbols share the same name, the standard nm output does not > > > > differentiate > > > > between them. This can lead to confusion and difficulty when trying to > > > > probe the intended symbol. > > > > > > > > ~ # cat /proc/kallsyms | grep " name_show" > > > > 8c4f76d0 t name_show > > > > 8c9cccb0 t name_show > > > > 8cb0ac20 t name_show > > > > 8cc728c0 t name_show > > > > 8ce0efd0 t name_show > > > > 8ce126c0 t name_show > > > > 8ce1dd20 t name_show > > > > 8ce24e70 t name_show > > > > 8d1104c0 t name_show > > > > 8d1fe480 t name_show > > > > > > One problem that remains as far as I can see is that this approach does > > > not > > > take into consideration that there can be duplicate symbols in the core > > > kernel, but also between core kernel and loadable modules, and even > > > between > > > loadable modules. So, I think more is needed to also ensure that this > > > approach of adding alias symbols is also done for loadable modules. > > > > To identify which symbols are duplicated, including those contained in > > modules, it requires exploring all the objects. If I were to propose a > > complementary tool to kas_alias that operates on modules, it would need to > > run on all objects to ascertain the state of the names. > > Only after this assessment could it produce its output. > > This would entail postponing the second kallsyms pass until after all > > modules have been processed. > > Additionally, modules would need to be processed twice: once to assess the > > names and a second time to generate aliases for duplicated symbols. > > I am uncertain if the community would be willing to accept such a delay in > > the build process to introduce this feature. > > >From the livepatching POV: > > + It needs a way to distinguish duplicate symbols within a module. > > + It does _not_ need to distinguish symbols which have the same name > in two modules or in a module and vmlinux. > > Background: The livepatch contains a structure where the livepatched > symbols are already split per-livepatched objects: vmlinux or modules. > I has to know whether a later loaded or removed module is livepatched > or not and what functions need some tweaking. Thank you for sharing the POV for livepatching. That is cery helpful. My follow-up email to
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Mon 2023-10-09 15:14:28, Alessandro Carminati wrote: > Hello Kris, > > Thank you for your contribution and for having your thought shared with me. > > Allow me to begin this conversation by explaining what came to mind when > I decided to propose a patch that creates aliases. > > The objective was to address a specific problem I was facing while > minimizing any potential impact on other aspects. > My initial consideration was the existence of numerous tools, both in the > kernel and in userspace, that rely on the current kallsyms implementation. > Both Nick and I shared the concern that making changes to elements upon > which these tools depend on could have significant consequences. > > To the best of my knowledge, Nick's strategy has been to duplicate kallsyms > with something new - a new, improved kallsyms file. > > However, even if Nick's patch were to be accepted, it wouldn't fully meet > my personal requirements. > This is because my goal was to utilize kprobe on a symbol that shares its > name with others. Nick's work wouldn't allow me to do this, and that's why, > I proposed an alternative. > > As a result, my strategy was more modest and focused solely on creating > aliases for duplicate symbols. > By adding these aliases, existing tools would remain unaffected, and the > current system state and ecosystem would be preserved. > For instance, mechanisms like live patching could continue to use the > symbol hit count. > > On the flip side, introducing these new symbols would enable tracers to > directly employ the new names without any modifications, and humans could > easily identify the symbol they are dealing with just by examining the > name. > These are the fundamental principles behind my patch - introducing aliases. > > Il giorno gio 5 ott 2023 alle ore 18:25 Kris Van Hees > ha scritto: > > > > On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) > > wrote: > > > It is not uncommon for drivers or modules related to similar peripherals > > > to have symbols with the exact same name. > > > While this is not a problem for the kernel's binary itself, it becomes an > > > issue when attempting to trace or probe specific functions using > > > infrastructure like ftrace or kprobe. > > > > > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > > > symbol information from the kernel's ELF binary. However, when multiple > > > symbols share the same name, the standard nm output does not differentiate > > > between them. This can lead to confusion and difficulty when trying to > > > probe the intended symbol. > > > > > > ~ # cat /proc/kallsyms | grep " name_show" > > > 8c4f76d0 t name_show > > > 8c9cccb0 t name_show > > > 8cb0ac20 t name_show > > > 8cc728c0 t name_show > > > 8ce0efd0 t name_show > > > 8ce126c0 t name_show > > > 8ce1dd20 t name_show > > > 8ce24e70 t name_show > > > 8d1104c0 t name_show > > > 8d1fe480 t name_show > > > > One problem that remains as far as I can see is that this approach does not > > take into consideration that there can be duplicate symbols in the core > > kernel, but also between core kernel and loadable modules, and even between > > loadable modules. So, I think more is needed to also ensure that this > > approach of adding alias symbols is also done for loadable modules. > > To identify which symbols are duplicated, including those contained in > modules, it requires exploring all the objects. If I were to propose a > complementary tool to kas_alias that operates on modules, it would need to > run on all objects to ascertain the state of the names. > Only after this assessment could it produce its output. > This would entail postponing the second kallsyms pass until after all > modules have been processed. > Additionally, modules would need to be processed twice: once to assess the > names and a second time to generate aliases for duplicated symbols. > I am uncertain if the community would be willing to accept such a delay in > the build process to introduce this feature. >From the livepatching POV: + It needs a way to distinguish duplicate symbols within a module. + It does _not_ need to distinguish symbols which have the same name in two modules or in a module and vmlinux. Background: The livepatch contains a structure where the livepatched symbols are already split per-livepatched objects: vmlinux or modules. I has to know whether a later loaded or removed module is livepatched or not and what functions need some tweaking. > > I'd be happy to work on something like this as a contribution to your work. > > I would envision the alias entry not needing to have the typical [module] > > added > > to it because that will already be annotated on the actual symbol entry. > > So, > > the alias could be extended to be something like: > > > > c0533720 t floppy_open [floppy] > > c0533720 t
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hello Kris, Thank you for your contribution and for having your thought shared with me. Allow me to begin this conversation by explaining what came to mind when I decided to propose a patch that creates aliases. The objective was to address a specific problem I was facing while minimizing any potential impact on other aspects. My initial consideration was the existence of numerous tools, both in the kernel and in userspace, that rely on the current kallsyms implementation. Both Nick and I shared the concern that making changes to elements upon which these tools depend on could have significant consequences. To the best of my knowledge, Nick's strategy has been to duplicate kallsyms with something new - a new, improved kallsyms file. However, even if Nick's patch were to be accepted, it wouldn't fully meet my personal requirements. This is because my goal was to utilize kprobe on a symbol that shares its name with others. Nick's work wouldn't allow me to do this, and that's why, I proposed an alternative. As a result, my strategy was more modest and focused solely on creating aliases for duplicate symbols. By adding these aliases, existing tools would remain unaffected, and the current system state and ecosystem would be preserved. For instance, mechanisms like live patching could continue to use the symbol hit count. On the flip side, introducing these new symbols would enable tracers to directly employ the new names without any modifications, and humans could easily identify the symbol they are dealing with just by examining the name. These are the fundamental principles behind my patch - introducing aliases. Il giorno gio 5 ott 2023 alle ore 18:25 Kris Van Hees ha scritto: > > On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) > wrote: > > It is not uncommon for drivers or modules related to similar peripherals > > to have symbols with the exact same name. > > While this is not a problem for the kernel's binary itself, it becomes an > > issue when attempting to trace or probe specific functions using > > infrastructure like ftrace or kprobe. > > > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > > symbol information from the kernel's ELF binary. However, when multiple > > symbols share the same name, the standard nm output does not differentiate > > between them. This can lead to confusion and difficulty when trying to > > probe the intended symbol. > > > > ~ # cat /proc/kallsyms | grep " name_show" > > 8c4f76d0 t name_show > > 8c9cccb0 t name_show > > 8cb0ac20 t name_show > > 8cc728c0 t name_show > > 8ce0efd0 t name_show > > 8ce126c0 t name_show > > 8ce1dd20 t name_show > > 8ce24e70 t name_show > > 8d1104c0 t name_show > > 8d1fe480 t name_show > > One problem that remains as far as I can see is that this approach does not > take into consideration that there can be duplicate symbols in the core > kernel, but also between core kernel and loadable modules, and even between > loadable modules. So, I think more is needed to also ensure that this > approach of adding alias symbols is also done for loadable modules. > > Earlier work that cover all symbols (core kernel and loadable modules) was > posted quite a while ago by Nick Alcock: > > https://lore.kernel.org/all/20221205163157.269335-1-nick.alc...@oracle.com/ > > It takes a different approach and adds in other info that is very useful for > tracing, but unfortunately it has been dormant for a long time now. > > While module symbols are handled quite differently (for kallsyms) from the > core kernel symbols, I think that a similar approach tied in with modpost > ought to be quite possible. It will add to the size of modules because the > data needs to be stored in the .ko but that is unavoidable. But not doing it > unfortunately would mean that the duplicate symbol issue remains unresolved > in the presence of loadable modules. > In the current implementation, my work is capable of "addressing" the issue only for duplicate symbols within the core kernel image. This is a fact. Currently, modules are not within the scope of my work. Originally, my intention was to deal with duplicates in modules as the subsequent objective. I agree with you that addressing duplicate symbols in modules is something that needs to be resolved, but from my perspective, it appeared to be of lesser importance. This is because, when trace tools are used manually, there is already an indication of the modules where the name originates. In this context, I would welcome the opportunity to explore additional use cases. By doing so, I can better align any future proposals with these real-world scenarios and requirements I'm not considering in this moment. In my initial intention, I had hoped to extend the use of aliases to modules as well. However, I encountered some challenges that need to be addressed first. If I were to
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Thu, Oct 05, 2023 at 12:24:03PM -0400, Kris Van Hees wrote: > On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) > wrote: > > It is not uncommon for drivers or modules related to similar peripherals > > to have symbols with the exact same name. > > While this is not a problem for the kernel's binary itself, it becomes an > > issue when attempting to trace or probe specific functions using > > infrastructure like ftrace or kprobe. > > > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > > symbol information from the kernel's ELF binary. However, when multiple > > symbols share the same name, the standard nm output does not differentiate > > between them. This can lead to confusion and difficulty when trying to > > probe the intended symbol. > > > > ~ # cat /proc/kallsyms | grep " name_show" > > 8c4f76d0 t name_show > > 8c9cccb0 t name_show > > 8cb0ac20 t name_show > > 8cc728c0 t name_show > > 8ce0efd0 t name_show > > 8ce126c0 t name_show > > 8ce1dd20 t name_show > > 8ce24e70 t name_show > > 8d1104c0 t name_show > > 8d1fe480 t name_show > > One problem that remains as far as I can see is that this approach does not > take into consideration that there can be duplicate symbols in the core > kernel, but also between core kernel and loadable modules, and even between > loadable modules. So, I think more is needed to also ensure that this > approach of adding alias symbols is also done for loadable modules. Re-reading my email a bit more, I realize that I did not accurate demonstrate the issue I arefer to. Obviously, the current patch provides aliases for duplicate symbols in the core kernel. And loadable modules are annotated with the module name. So, all is well unless modules have duplicate symbols themselves. And although it is rare, it does happen: # grep ' metadata_show' /proc/kallsyms c05659c0 t metadata_show[md_mod] c05739f0 t metadata_show[md_mod] This again shows a case where there are duplicate symbols that cannot be distinguished for tracing purposes without additional information. So, the proposed patch unfortunately does not cover all cases because of loadable modules. > Earlier work that cover all symbols (core kernel and loadable modules) was > posted quite a while ago by Nick Alcock: > > https://lore.kernel.org/all/20221205163157.269335-1-nick.alc...@oracle.com/ > > It takes a different approach and adds in other info that is very useful for > tracing, but unfortunately it has been dormant for a long time now. > > While module symbols are handled quite differently (for kallsyms) from the > core kernel symbols, I think that a similar approach tied in with modpost > ought to be quite possible. It will add to the size of modules because the > data needs to be stored in the .ko but that is unavoidable. But not doing it > unfortunately would mean that the duplicate symbol issue remains unresolved > in the presence of loadable modules. > > > kas_alias addresses this challenge by enhancing symbol names with > > meaningful suffixes generated from the source file and line number > > during the kernel build process. > > These newly generated aliases provide tracers with the ability to > > comprehend the symbols they are interacting with when utilizing the > > ftracefs interface. > > This approach may also allow for the probing by name of previously > > inaccessible symbols. > > > > ~ # cat /proc/kallsyms | grep gic_mask_irq > > d15671e505ac t gic_mask_irq > > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > > d15671e532a4 t gic_mask_irq > > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > > ~ # > > In the same context as mentioned above (module symbols), I am hoping that the > alias you generate might also be able to contain a module identifier name, > much like the aforementioned patch series by Nick Alcock added. We have it > for loadable modules already of course, but as has been discussed in relation > to the earlier work, being able to associate a module name with a symbol > regardless of whether that module is configured to be built into the kernel > or whether it is configured to be a loadable module is helpful for tracing > purposes. Especially for tracers that use tracing scripts that might get > deployed on diverse systems where it cannot always be known at the time of > developing the tracer scripts whether a kernel module is configured to be > loadable or built-in. > > I'd be happy to work on something like this as a contribution to your work. > I would envision the alias entry not needing to have the typical [module] > added > to it because that will already be annotated on the actual symbol entry. So, > the alias could be extended to be something like: > > c0533720 t floppy_open [floppy] > c0533720 t
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) wrote: > It is not uncommon for drivers or modules related to similar peripherals > to have symbols with the exact same name. > While this is not a problem for the kernel's binary itself, it becomes an > issue when attempting to trace or probe specific functions using > infrastructure like ftrace or kprobe. > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > symbol information from the kernel's ELF binary. However, when multiple > symbols share the same name, the standard nm output does not differentiate > between them. This can lead to confusion and difficulty when trying to > probe the intended symbol. > > ~ # cat /proc/kallsyms | grep " name_show" > 8c4f76d0 t name_show > 8c9cccb0 t name_show > 8cb0ac20 t name_show > 8cc728c0 t name_show > 8ce0efd0 t name_show > 8ce126c0 t name_show > 8ce1dd20 t name_show > 8ce24e70 t name_show > 8d1104c0 t name_show > 8d1fe480 t name_show One problem that remains as far as I can see is that this approach does not take into consideration that there can be duplicate symbols in the core kernel, but also between core kernel and loadable modules, and even between loadable modules. So, I think more is needed to also ensure that this approach of adding alias symbols is also done for loadable modules. Earlier work that cover all symbols (core kernel and loadable modules) was posted quite a while ago by Nick Alcock: https://lore.kernel.org/all/20221205163157.269335-1-nick.alc...@oracle.com/ It takes a different approach and adds in other info that is very useful for tracing, but unfortunately it has been dormant for a long time now. While module symbols are handled quite differently (for kallsyms) from the core kernel symbols, I think that a similar approach tied in with modpost ought to be quite possible. It will add to the size of modules because the data needs to be stored in the .ko but that is unavoidable. But not doing it unfortunately would mean that the duplicate symbol issue remains unresolved in the presence of loadable modules. > kas_alias addresses this challenge by enhancing symbol names with > meaningful suffixes generated from the source file and line number > during the kernel build process. > These newly generated aliases provide tracers with the ability to > comprehend the symbols they are interacting with when utilizing the > ftracefs interface. > This approach may also allow for the probing by name of previously > inaccessible symbols. > > ~ # cat /proc/kallsyms | grep gic_mask_irq > d15671e505ac t gic_mask_irq > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > d15671e532a4 t gic_mask_irq > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > ~ # In the same context as mentioned above (module symbols), I am hoping that the alias you generate might also be able to contain a module identifier name, much like the aforementioned patch series by Nick Alcock added. We have it for loadable modules already of course, but as has been discussed in relation to the earlier work, being able to associate a module name with a symbol regardless of whether that module is configured to be built into the kernel or whether it is configured to be a loadable module is helpful for tracing purposes. Especially for tracers that use tracing scripts that might get deployed on diverse systems where it cannot always be known at the time of developing the tracer scripts whether a kernel module is configured to be loadable or built-in. I'd be happy to work on something like this as a contribution to your work. I would envision the alias entry not needing to have the typical [module] added to it because that will already be annotated on the actual symbol entry. So, the alias could be extended to be something like: c0533720 t floppy_open [floppy] c0533720 t floppy_open@floppy:drivers_block_floppy_c_3988 (absence of a name: prefix to the path would indicate the symbol is not associated with any module) Doing this is more realistic now as a result of the clean-up patches that Nick introduced, e.g. https://lore.kernel.org/lkml/20230302211759.30135-1-nick.alc...@oracle.com/ > 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. > >
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hi. Le mercredi 27 septembre 2023, 20:35:16 EEST Alessandro Carminati (Red Hat) a écrit : > It is not uncommon for drivers or modules related to similar peripherals > to have symbols with the exact same name. > While this is not a problem for the kernel's binary itself, it becomes an > issue when attempting to trace or probe specific functions using > infrastructure like ftrace or kprobe. > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > symbol information from the kernel's ELF binary. However, when multiple > symbols share the same name, the standard nm output does not differentiate > between them. This can lead to confusion and difficulty when trying to > probe the intended symbol. > > ~ # cat /proc/kallsyms | grep " name_show" > 8c4f76d0 t name_show > 8c9cccb0 t name_show > 8cb0ac20 t name_show > 8cc728c0 t name_show > 8ce0efd0 t name_show > 8ce126c0 t name_show > 8ce1dd20 t name_show > 8ce24e70 t name_show > 8d1104c0 t name_show > 8d1fe480 t name_show > > kas_alias addresses this challenge by enhancing symbol names with > meaningful suffixes generated from the source file and line number > during the kernel build process. > These newly generated aliases provide tracers with the ability to > comprehend the symbols they are interacting with when utilizing the > ftracefs interface. > This approach may also allow for the probing by name of previously > inaccessible symbols. > > ~ # cat /proc/kallsyms | grep gic_mask_irq > d15671e505ac t gic_mask_irq > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > d15671e532a4 t gic_mask_irq > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > ~ # > > 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.carminati@gm > ail.com/ > > Changes from v2: > - Alias tags are created by querying DWARF information from the vmlinux. > - The filename + line number is normalized and appended to the original > name. > - The tag begins with '@' to indicate the symbol source. > - Not a change, but worth mentioning, since the alias is added to the > existing list, the old duplicated name is preserved, and the livepatch > way of dealing with duplicates is maintained. > - Acknowledging the existence of scenarios where inlined functions > declared in header files may result in multiple copies due to compiler > behavior, though it is not actionable as it does not pose an operational > issue. > - Highlighting a single exception where the same name refers to different > functions: the case of "compat_binfmt_elf.c," which directly includes > "binfmt_elf.c" producing identical function copies in two separate > modules. > > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carminati@gm > ail.com/ > > Changes from v3: > - kas_alias was rewritten in Python to create a more concise and > maintainable codebase. > - The previous automation process used by kas_alias to locate the vmlinux > and the addr2line has been replaced with an explicit command-line switch > for specifying these requirements. > - addr2line has been added into the main Makefile. > - A new command-line switch has been introduced, enabling users to extend > the alias to global data names. > > https://lore.kernel.org/all/20230828080423.3539686-1-alessandro.carminati@gm > ail.com/ > > Changes from v4: > - Fixed the O= build issue > - The tool halts execution upon encountering major issues, thereby ensuring > the pipeline is interrupted. > - A cmdline option to specify the source directory added. > - Minor code adjusments. > - Tested on mips32 and i386 Thank you for sending this new version! I only found nits and I think we are near its merge! > https://lore.kernel.org/all/20230919193948.465340-1-alessandro.carminati@gma > il.com/ > > NOTE: > 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
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hello Masami, Thank you for your feedback. Il giorno ven 29 set 2023 alle ore 13:28 Masami Hiramatsu ha scritto: > > On Wed, 27 Sep 2023 17:35:16 + > "Alessandro Carminati (Red Hat)" wrote: > > > It is not uncommon for drivers or modules related to similar peripherals > > to have symbols with the exact same name. > > While this is not a problem for the kernel's binary itself, it becomes an > > issue when attempting to trace or probe specific functions using > > infrastructure like ftrace or kprobe. > > > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > > symbol information from the kernel's ELF binary. However, when multiple > > symbols share the same name, the standard nm output does not differentiate > > between them. This can lead to confusion and difficulty when trying to > > probe the intended symbol. > > > > ~ # cat /proc/kallsyms | grep " name_show" > > 8c4f76d0 t name_show > > 8c9cccb0 t name_show > > 8cb0ac20 t name_show > > 8cc728c0 t name_show > > 8ce0efd0 t name_show > > 8ce126c0 t name_show > > 8ce1dd20 t name_show > > 8ce24e70 t name_show > > 8d1104c0 t name_show > > 8d1fe480 t name_show > > > > kas_alias addresses this challenge by enhancing symbol names with > > meaningful suffixes generated from the source file and line number > > during the kernel build process. > > These newly generated aliases provide tracers with the ability to > > comprehend the symbols they are interacting with when utilizing the > > ftracefs interface. > > This approach may also allow for the probing by name of previously > > inaccessible symbols. > > > > ~ # cat /proc/kallsyms | grep gic_mask_irq > > d15671e505ac t gic_mask_irq > > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > > d15671e532a4 t gic_mask_irq > > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > > ~ # > > > > 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 filename + line number is normalized and appended to the original > > name. > > - The tag begins with '@' to indicate the symbol source. > > - Not a change, but worth mentioning, since the alias is added to the > > existing list, the old duplicated name is preserved, and the livepatch > > way of dealing with duplicates is maintained. > > - Acknowledging the existence of scenarios where inlined functions > > declared in header files may result in multiple copies due to compiler > > behavior, though it is not actionable as it does not pose an operational > > issue. > > - Highlighting a single exception where the same name refers to different > > functions: the case of "compat_binfmt_elf.c," which directly includes > > "binfmt_elf.c" producing identical function copies in two separate > > modules. > > > > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carmin...@gmail.com/ > > > > Changes from v3: > > - kas_alias was rewritten in Python to create a more concise and > > maintainable codebase. > > - The previous automation process used by kas_alias to locate the vmlinux > > and the addr2line has been replaced with an explicit command-line switch > > for specifying these requirements. > > - addr2line has been added into the main Makefile. > > - A new command-line switch has been introduced, enabling users to extend > > the alias to global data names. > > > > https://lore.kernel.org/all/20230828080423.3539686-1-alessandro.carmin...@gmail.com/ > > > > Changes from v4: > > - Fixed the O= build issue > > - The tool halts execution upon encountering major issues, thereby ensuring > > the pipeline is interrupted. > > - A cmdline option to specify the source directory added. > > - Minor code adjusments. > > - Tested on mips32 and i386 > > > > https://lore.kernel.org/all/20230919193948.465340-1-alessandro.carmin...@gmail.com/ > > > > NOTE: > > 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
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Wed, 27 Sep 2023 17:35:16 + "Alessandro Carminati (Red Hat)" wrote: > It is not uncommon for drivers or modules related to similar peripherals > to have symbols with the exact same name. > While this is not a problem for the kernel's binary itself, it becomes an > issue when attempting to trace or probe specific functions using > infrastructure like ftrace or kprobe. > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > symbol information from the kernel's ELF binary. However, when multiple > symbols share the same name, the standard nm output does not differentiate > between them. This can lead to confusion and difficulty when trying to > probe the intended symbol. > > ~ # cat /proc/kallsyms | grep " name_show" > 8c4f76d0 t name_show > 8c9cccb0 t name_show > 8cb0ac20 t name_show > 8cc728c0 t name_show > 8ce0efd0 t name_show > 8ce126c0 t name_show > 8ce1dd20 t name_show > 8ce24e70 t name_show > 8d1104c0 t name_show > 8d1fe480 t name_show > > kas_alias addresses this challenge by enhancing symbol names with > meaningful suffixes generated from the source file and line number > during the kernel build process. > These newly generated aliases provide tracers with the ability to > comprehend the symbols they are interacting with when utilizing the > ftracefs interface. > This approach may also allow for the probing by name of previously > inaccessible symbols. > > ~ # cat /proc/kallsyms | grep gic_mask_irq > d15671e505ac t gic_mask_irq > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > d15671e532a4 t gic_mask_irq > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > ~ # > > 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 filename + line number is normalized and appended to the original > name. > - The tag begins with '@' to indicate the symbol source. > - Not a change, but worth mentioning, since the alias is added to the > existing list, the old duplicated name is preserved, and the livepatch > way of dealing with duplicates is maintained. > - Acknowledging the existence of scenarios where inlined functions > declared in header files may result in multiple copies due to compiler > behavior, though it is not actionable as it does not pose an operational > issue. > - Highlighting a single exception where the same name refers to different > functions: the case of "compat_binfmt_elf.c," which directly includes > "binfmt_elf.c" producing identical function copies in two separate > modules. > > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carmin...@gmail.com/ > > Changes from v3: > - kas_alias was rewritten in Python to create a more concise and > maintainable codebase. > - The previous automation process used by kas_alias to locate the vmlinux > and the addr2line has been replaced with an explicit command-line switch > for specifying these requirements. > - addr2line has been added into the main Makefile. > - A new command-line switch has been introduced, enabling users to extend > the alias to global data names. > > https://lore.kernel.org/all/20230828080423.3539686-1-alessandro.carmin...@gmail.com/ > > Changes from v4: > - Fixed the O= build issue > - The tool halts execution upon encountering major issues, thereby ensuring > the pipeline is interrupted. > - A cmdline option to specify the source directory added. > - Minor code adjusments. > - Tested on mips32 and i386 > > https://lore.kernel.org/all/20230919193948.465340-1-alessandro.carmin...@gmail.com/ > > NOTE: > 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
