Re: [PATCH v2 dwarves 4/5] man-pages: document true_signature btf_feature
Alan Maguire <[email protected]>
| Newsgroups | org.kernel.vger.dwarves,org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
On 26/01/2026 11:21, Matt Bobrowski wrote: > 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 <[email protected]> >>> >>> Acked-by: Matt Bobrowski <[email protected]> >>> >>>> --- >>>> 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? Yep, we're hoping to get some support on the LLVM side for true signatures, but absolutely, that's the plan. Because the --btf_features option will simply ignore features that it does not know about, this approach works with older pahole too without erroring out.