Re: [PATCH dwarves v1 0/3] btf_encoder: support for BPF magic kernel functions

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

On 11/4/25 12:59 PM, Alan Maguire wrote:
> On 29/10/2025 19:02, Ihor Solodrai wrote:
>> This series implements BTF encoding of BPF kernel functions marked
>> with KF_MAGIC_ARGS flag in pahole.
>>
>> The kfunc flag indicates that the arguments of a kfunc with __magic
>> suffix are implicitly set by the verifier, and so pahole must emit two
>> functions to BTF:
>>   * kfunc_impl() with the arguments matching kernel declaration
>>   * kfunc() with __magic arguments omitted
>>
>> For more details see relevant patch series for BPF:
>> "bpf: magic kernel functions"
>>
>> This series is built upon KF_IMPLICIT_PROG_AUX_ARG support [1],
>> although the approach changed signifcantly to call it a v2.
>>
>> [1] https://lore.kernel.org/dwarves/20250924211512.1287298-1-ihor.solodrai@linux.dev/
>>
>> Ihor Solodrai (3):
>>   btf_encoder: refactor btf_encoder__add_func_proto
>>   btf_encoder: factor out btf_encoder__add_bpf_kfunc()
>>   btf_encoder: support kfuncs with KF_MAGIC_ARGS flag
>>
>>  btf_encoder.c | 292 ++++++++++++++++++++++++++++++++++++++------------
>>  1 file changed, 222 insertions(+), 70 deletions(-)
>>
> 
> seems like we could potentially pull in patches 1 and 2 as cleanups
> prior to handling the KF_MAGIC/IMPLICIT change; would that be worthwhile?
> 

Hi Alan.

Feel free to merge in the refactoring patches if you think they are
useful. No objections.

I've had another off-list discussion with Andrii, and I am going to
try implementing the next iteration of KF_IMPLICIT_ARGS (no magic,
sorry) feature via resolve_btfids in the kernel tree.

As you of course well know, maintaining backwards compatibility by
tracking pahole version and ensuring correct feature flags in the
Linux kernel build has been tiresome.

We are thinking to address this by separating BTF generation for the
kernel into two independent stages:
  * generate BTF from DWARF with pahole
  * then modify BTF with kernel-specific transformations (with
    resolve_btfids, or however we rename it)

This will reduce the burden from pahole to know the kernel-specific
tweaks of the BTF: adding kfunc decl tags, handling kernel function
flags, etc. pahole will only be concerned with "generic" BTF
generation from DWARF.

This will also free us from the need to control exactly what pahole
features are available (maybe except specifying minimum version) in
the kernel build, because btf2btf transformations will live in the
Linux tree.

KF_IMPLICIT_ARGS will be the proof-of-concept for the approach. If it
works well, then eventually we can migrate existing kernel-specific
BTF generation out from pahole.

Let me know what you think about all this.

Thank you.


> Thanks!
> 
> Alan