On 21 Jul 2025, Jiri Olsa verbalised: > On Mon, Jul 21, 2025 at 12:41:00PM +0100, Alan Maguire wrote: >> On 17/07/2025 16:25, Jiri Olsa wrote: >> > Menglong reported issue where we can have function in BTF which has >> > multiple addresses in kallsysm [1]. >> > >> > Rather than filtering this in runtime, let's teach pahole to remove >> > such functions. >> > >> > Removing duplicate records from functions entries that have more >> > at least one different address. This way btf_encoder__find_function >> > won't find such functions and they won't be added in BTF. >> > >> > In my setup it removed 428 functions out of 77141. >> > >> >> Is such removal necessary? If the presence of an mcount annotation is >> the requirement, couldn't we just utilize >> >> /sys/kernel/tracing/available_filter_functions_addrs >> >> to map name to address safely? It identifies mcount-containing functions >> and some of these appear to be duplicates, for example there I see >> >> ffffffff8376e8b4 acpi_attr_is_visible >> ffffffff8379b7d4 acpi_attr_is_visible > > for that we'd need new interface for loading fentry/fexit.. programs, right? > > the current interface to get fentry/fexit.. attach address is: > - user specifies function name, that translates to btf_id > - in kernel that btf id translates back to function name > - kernel uses kallsyms_lookup_name or find_kallsyms_symbol_value > to get the address > > so we don't really know which address user wanted in the first place > > I think we discussed this issue some time ago, but I'm not sure what > the proposal was at the end (function address stored in BTF?) Function address, translation unit name, *some* disambiguator. Really both seem like they might be useful in different situations. -- NULL && (void)
