Re: [PATCH v2 dwarves 4/5] man-pages: document true_signature btf_feature

Matt Bobrowski
2026-01-26T11:21:10Z

On Mon, Jan 26, 2026 at 10:51:31AM +0000, Alan Maguire wrote:
> On 26/01/2026 10:02, Matt Bobrowski wrote:
> > On Fri, Jan 23, 2026 at 05:26:49PM +0000, Alan Maguire wrote:
> >> Ensure non-default "true_signature" feature is documented in
> >> the manual page.
> >>
> >> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> >
> > Acked-by: Matt Bobrowski <mattbobrowski@google.com>
> >
> >> ---
> >> man-pages/pahole.1 | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/man-pages/pahole.1 b/man-pages/pahole.1
> >> index 3125de3..90a8f45 100644
> >> --- a/man-pages/pahole.1
> >> +++ b/man-pages/pahole.1
> >> @@ -337,6 +337,11 @@ Supported non-standard features (not enabled for 'default')
> >> of split BTF with a possibly changed base, storing
> >> it in a .BTF.base ELF section.
> >> global_var Encode all global variables using BTF_KIND_VAR in BTF.
> >> + true_signature Encode functions ensuring that binary-level
> >> + (rather than source-level) signatures are used;
> > ^
> > within the generated BTF.
> >
> >> + for gcc these are ".isra.0" and ".costprop.0"
> >> + optimized functions
> >
> > For BTF generation, would there ever be a situation whereby we
> > wouldn't want true signature support? I'm just trying to understand
> > why this isn't defaulted to true.
>
> The key reason is the "." in the name for gcc-optimized functions
> "function.isra.0" ; older kernels will reject BTF function names with
> a "." in them, so we have to guard against new pahole with the feature
> enabled by default being run on older kernels. So by having the newer
> kernels request the feature only we avoid this.

Oh, yes, that makes sense. Once a new pahole version is released with
true_signature support available, will you also be looking to update
scripts/Makefile.btf and conditionally enable it based on
availability?