On 7/28/25 8:19 PM, Ihor Solodrai wrote:
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?..
Never mind, I think it's some security rules on Meta side.
Alan, please let me know if you received the patch, or if I should
resend again. Thanks.
