Re: [PATCH bpf-next v3 4/6] lib/Kconfig.debug: Set the minimum required pahole version to v1.22

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 12/12/25 9:26 AM, Alan Maguire wrote:
> On 05/12/2025 22:30, Ihor Solodrai wrote:
>> Subsequent patches in the series change vmlinux linking scripts to
>> unconditionally pass --btf_encode_detached to pahole, which was
>> introduced in v1.22 [1][2].
>>
>> This change allows to remove PAHOLE_HAS_SPLIT_BTF Kconfig option and
>> other checks of older pahole versions.
>>
>> [1] https://github.com/acmel/dwarves/releases/tag/v1.22
>> [2] https://lore.kernel.org/bpf/cbafbf4e-9073-4383-8ee6-1353f9e5869c@oracle.com/
>>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
>>  lib/Kconfig.debug         | 13 ++++---------
>>  scripts/Makefile.btf      |  9 +--------
>>  tools/sched_ext/README.md |  1 -
>>  3 files changed, 5 insertions(+), 18 deletions(-)
>>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 742b23ef0d8b..3abf3ae554b6 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -389,18 +389,13 @@ config DEBUG_INFO_BTF
>>  	depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>>  	depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
>>  	depends on BPF_SYSCALL
>> -	depends on PAHOLE_VERSION >= 116
>> -	depends on DEBUG_INFO_DWARF4 || PAHOLE_VERSION >= 121
>> +	depends on PAHOLE_VERSION >= 122
>>  	# pahole uses elfutils, which does not have support for Hexagon relocations
>>  	depends on !HEXAGON
>>  	help
>>  	  Generate deduplicated BTF type information from DWARF debug info.
>> -	  Turning this on requires pahole v1.16 or later (v1.21 or later to
>> -	  support DWARF 5), which will convert DWARF type info into equivalent
>> -	  deduplicated BTF type info.
>> -
>> -config PAHOLE_HAS_SPLIT_BTF
>> -	def_bool PAHOLE_VERSION >= 119
>> +	  Turning this on requires pahole v1.22 or later, which will convert
>> +	  DWARF type info into equivalent deduplicated BTF type info.
>>  
>>  config PAHOLE_HAS_BTF_TAG
>>  	def_bool PAHOLE_VERSION >= 123
>> @@ -422,7 +417,7 @@ config PAHOLE_HAS_LANG_EXCLUDE
>>  config DEBUG_INFO_BTF_MODULES
>>  	bool "Generate BTF type information for kernel modules"
>>  	default y
>> -	depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF
>> +	depends on DEBUG_INFO_BTF && MODULES
>>  	help
>>  	  Generate compact split BTF type information for kernel modules.
>>  
>> diff --git a/scripts/Makefile.btf b/scripts/Makefile.btf
>> index db76335dd917..7c1cd6c2ff75 100644
>> --- a/scripts/Makefile.btf
>> +++ b/scripts/Makefile.btf
>> @@ -7,14 +7,7 @@ JOBS := $(patsubst -j%,%,$(filter -j%,$(MAKEFLAGS)))
>>
> 
> hi Ihor, a small suggestion here, and it is orthogonal to what you're 
> doing here, so just for consideration if you're planning a v4 since you're 
> touching this file.

Hi Alan. v4 for sure, and maybe even v5, we'll see.

> 
> We've had problems in the past because we get pahole version from .config
> in Makefile.btf
> 
> pahole-ver := $(CONFIG_PAHOLE_VERSION)
> 
> and it can be outdated.
> 
> Specifically the problem is that if "make oldconfig" is not run after
> updating pahole we don't get the actual pahole version during builds
> and options can be missing. See [1] for an example, but perhaps we
> should do
> 
> pahole-ver := $(shell $(srctree)/scripts/pahole-version.sh)
> 
> in Makefile.btf to ensure the value reflects latest pahole and that
> then determines which options we use? Andrii suggested an approach like
> CC_VERSION_TEXT might be worth pursuing; AFAICT that recomputes the
> CC_VERSION and warns the user if there is a version difference. Given that
> the CONFIG pahole version requirements are all pretty modest - it might
> simply be enough to recompute it in Makefile.btf and perhaps ensure it's 
> not less than CONFIG_PAHOLE_VERSION. Just a thought anyway. Thanks!

Yeah, I am aware of the issue.

I am not sure version refresh in Makefile.btf would be enough, since
there are config dependencies in Kconfig.debug.  So we either need to
trigger re-config, and maybe even force full kernel re-build, or
somehow get rid of the version checks in the kconfig, which may be a
challenge.

I think the simplest thing we could is to check if the version has
changed and fail the build. That's a "panic!" approach though.

I'll look into how compiler versions are checked, maybe it's not that
hard to add similar behavior for pahole.


> 
> Alan
>  
> [1] https://lore.kernel.org/bpf/CAEf4BzYi1xX3p_bY3j9dEuPvtCW3H7z=p2vdn-2GY0OOenxQAg@mail.gmail.com/
>