On 7/28/25 7:03 PM, Ihor Solodrai wrote:
btf_encoder collects function ELF symbols into a table, which is later used for processing DWARF data and determining whether a function can be added to BTF. So far the ELF symbol name was used as a key for search in this table, and a search by prefix match was attempted in cases when ELF symbol name has a compiler-generated suffix. This implementation has bugs [1][2], causing some functions to be inappropriately excluded from (or included into) BTF. Rework the implementation of the ELF functions table. Use a name of a function without any suffix - symbol name before the first occurrence of '.' - as a key. This way btf_encoder__find_function() always returns a valid elf_function object (or NULL). Collect an array of symbol name + address pairs from GElf_Sym for each elf_function when building the elf_functions table. Introduce ambiguous_addr flag to the btf_encoder_func_state. It is set when the function is saved by examining the array of ELF symbols in elf_function__has_ambiguous_address(). It tests whether there is only one unique address for this function name, taking into account that some addresses associated with it are not relevant: * ".cold" suffix indicates a piece of hot/cold split * ".part" suffix indicates a piece of partial inline When inspecting symbol name we have to search for any occurrence of the target suffix, as opposed to testing the entire suffix, or the end of a string. This is because suffixes may be combined by the compiler, for example producing ".isra0.cold", and the conclusion will be incorrect. In saved_functions_combine() check ambiguous_addr when deciding whether a function should be included in BTF. Successful CI run: https://github.com/acmel/dwarves/pull/68/checks I manually spot checked some of the ~200 functions from vmlinux (BPF CI-like kconfig) that are now excluded: all of those that I checked had multiple addresses, and some where static functions from different files with the same name. [1] https://lore.kernel.org/bpf/2f8c792e-9675-4385-b1cb-10266c72bd45@xxxxxxxxx/ [2] https://lore.kernel.org/dwarves/6b4fda90fbf8f6aeeb2732bbfb6e81ba5669e2f3@xxxxxxxxx/ v1: https://lore.kernel.org/dwarves/98f41eaf6dd364745013650d58c5f254a592221c@xxxxxxxxx/ Signed-off-by: Ihor Solodrai <isolodrai@xxxxxxxx> [...]
Not sure what's wrong, but it appears this message can't reach vger.kernel.org, or maybe is spam filtered. I sent to vger.kernel.org from @meta.com email in the past w/o issues. Any suggestions?..
