Re: [PATCH bpf-next v3 0/4] btf_encoder: emit type tags for bpf_arena pointers

[Alan Maguire <alan.maguire@oracle.com>]

On 24/02/2025 20:32, Ihor Solodrai wrote:
> On 2/21/25 6:47 AM, Alan Maguire wrote:
>> On 19/02/2025 21:05, Ihor Solodrai wrote:
>>> This patch series implements emitting appropriate BTF type tags for
>>> argument and return types of kfuncs marked with KF_ARENA_* flags.
>>>
>>> For additional context see the description of BPF patch
>>> "bpf: define KF_ARENA_* flags for bpf_arena kfuncs" [1].
>>>
>>> The feature depends on recent changes in libbpf [2].
>>>
>>> [1] https://lore.kernel.org/bpf/20250206003148.2308659-1-ihor.solodrai@linux.dev/
>>> [2] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev/
>>>
>>
>> hi Ihor, just realized that given that this change depends on recent
>> libbpf changes, we should look at updating the series to include a patch
>> updating our libbpf subproject checkpoint commit for libbpf to get those
>> changes for the case where the libbpf submodule is built (the default
>> these days). We should probably have a patch (pahole: sync with
>> libbpf-1.6) to cover this. An example of a subproject commit patch can
>> be found at
>>
>> https://lore.kernel.org/dwarves/20240729111317.140816-2-alan.maguire@oracle.com/
>>
>> However I don't think those bpf-next libbpf changes have been synced
>> with the github libbpf repo yet. If the next libbf sync won't be for a
>> while, I don't think this has to block this work - we could just note
>> that it needs to explicitly be built with latest v1.6 via shared library
>> for testing purposes in the interim - but if there's a sync planned soon
>> it'd be great to roll that in too.
> 
> Hi Alan. I've just submitted a PR to sync libbpf with upstream.
> https://github.com/libbpf/libbpf/pull/886
> 
> Will add a subproject commit patch.
>

Fantastic, thank you!

> Andrii suggested pahole could use __weak declarations of libbpf API
> and detect if they are linked at runtime. This way it's not necessary
> to check for libbpf version. There are just a few places where we
> currently do that.
> 
> What do you think if I add patches for that too?
> 

That would be great! The current approach of static build-time version
checking isn't ideal, especially for folks using a dynamically linked
libbpf.

Alan

> Thanks.
> 
>>
>> Thanks!
>>
>> Alan
>>
>>  > v2->v3:
>>>   * Nits in patch #1
>>>
>>> v1->v2:
>>>   * Rewrite patch #1 refactoring btf_encoder__tag_kfuncs(): now the
>>>     post-processing step is removed entirely, and kfuncs are tagged in
>>>     btf_encoder__add_func().
>>>   * Nits and renames in patch #2
>>>   * Add patch #4 editing man pages
>>>
>>> v2: https://lore.kernel.org/dwarves/20250212201552.1431219-1-ihor.solodrai@linux.dev/
>>> v1: https://lore.kernel.org/dwarves/20250207021442.155703-1-ihor.solodrai@linux.dev/
>>>
>>> Ihor Solodrai (4):
>>>   btf_encoder: refactor btf_encoder__tag_kfuncs()
>>>   btf_encoder: emit type tags for bpf_arena pointers
>>>   pahole: introduce --btf_feature=attributes
>>>   man-pages: describe attributes and remove reproducible_build
>>>
>>>  btf_encoder.c      | 279 +++++++++++++++++++++++----------------------
>>>  dwarves.h          |   1 +
>>>  man-pages/pahole.1 |   7 +-
>>>  pahole.c           |  11 ++
>>>  4 files changed, 158 insertions(+), 140 deletions(-)
>>>
>>