Re: [PATCH v3 dwarves 0/5] Improve BTF concrete function accuracy

On 27/01/2026 17:20, 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 adds GCC true function signature support for optimized
> functions; with that support, we use binary-level signatures
> for .isra.0, .constprop.0 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 3 uses Yonghong's example program as a test; compiling
> with -O2 we expect a parameter to "foo" to be optimized
> out and the true function signature should reflect that.
> 
> Patch 4 documents the non-default "true_signature" feature.
> 
> Patch 5 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-2 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.
>

I'm planning on landing this series shortly, so if anyone has
any additional feedback/objections do let me know. Thanks!
 
Alan