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

Alan Maguire
2025-11-14T18:33:41Z

On 04/11/2025 22:25, Ihor Solodrai wrote:
> 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.
>

This sounds great to me; separating the basic BTF generation from the
handling of kernel-specific transformations makes a lot of sense. In a
way we've been conflating core BTF types (enum64, float) and BTF
kernel-specific features up until now. These evolve at different speeds
and the latter is naturally more kernel-tied, so I think the separation
makes a lot of sense. It'd be nice to give resolve_btfids a more
descriptive name if its role changes in this way, but let's not open
another naming can of worms now ;-)

Alan

> Thank you.
>
>
>> Thanks!
>>
>> Alan
>