Re: [PATCH dwarves 0/4] Improve BTF concrete function accuracy
Alan Maguire <[email protected]>
| Newsgroups | org.kernel.vger.dwarves,org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
On 13/01/2026 13:13, Alan Maguire wrote: > This series brings together a few solutions to issues we have > with accuracy of BTF function representation at the binary level. > > The first patch detects mismatches between concrete (binary) > and abstract (source-level) function signatures as a means > of either excluding them or providing a "true" function signature. > > Patch 2 is from Yonghong's LLVM true function signature series, > and helps for patch 3 which adds GCC true function signature > support for optimized functions; with that support, we use > binary-level signatures for .isra, .constprop functions and > represent them with their "." suffixes as BTF_KIND_FUNC > names. This allows for fentry attach to such functions, and > the "." suffix is an indicator of signature modification. > The feature is guarded by a default-off BTF feature because > older kernels did not support a "." in a function name. > > Patch 4 is Matt's patch to favour the strong function > over the associated weak declaration. The other patches > are important prerequisites for this as the patch selects > the binary-level function (with a lowpc value), and in > the case of optimized functions we were often selecting > the .isra function with optimized-out parameters. Because > pahole did not previously detect this correctly we ended > up with functions with signatures having reordered parameters. > > Patches 1-3 help avoid this by better detecting optimized-out > function parameters. > > With these patches in place, ~20 functions are omitted from > vmlinux BTF; all these are "."-suffixed functions which > we were not noticing had optimized-out parameters. > > Experimenting with adding true_signature to BTF features > we end up adding approximately 500 .isra and .constprop > functions to vmlinux BTF. > > The true function signature support here will also hopefully > help pave the way for Yonghong's work on the LLVM side. > hi folks, I'd like to land this series (patches 1, 3 and 4; patch 2 isn't needed right now) soon so we have Matt's fix in place; if anyone has cycles to further look at the patches or test it to ensure the vmlinux and module BTF generated doesn't cause problems, that would be great. Thanks! Alan