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

[Yonghong Song <yonghong.song@linux.dev>]

On 1/26/26 9:10 AM, Alan Maguire wrote:
> 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.

I actually have started to work on this from llvm side. Once Alan's patch
lands (which has true_signature infrastructure implemented), I should be
able to send some patch to address true_signature for llvm-built kernel.