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

Alan Maguire
2026-01-26T17:10:21Z

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 <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?

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.