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

Ihor Solodrai
2025-12-16T02:41:14Z

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