Re: [PATCH bpf-next 1/2] tools/lib/bpf: bpf_program__insns allow to retrieve insns in libbpf

[Lorenzo Fontana <fontanalorenz@gmail.com>]

On 7/16/21 3:51 AM, Alexei Starovoitov wrote:
> On Thu, Jul 15, 2021 at 2:40 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
>> On Tue, Jul 13, 2021 at 11:34 AM Lorenzo Fontana
>> <fontanalorenz@gmail.com> wrote:
>>> This allows consumers of libbpf to iterate trough the insns
>>> of a program without loading it first directly after the ELF parsing.
>>>
>>> Being able to do that is useful to create tooling that can show
>>> the structure of a BPF program using libbpf without having to
>>> parse the ELF separately.
>>>
>> So I wonder how useful is getting raw BPF instructions before libbpf
>> processed them and resolved map references, subprogram calls, etc?
>> You'll have lots of zeroes or meaningless constants in ldimm64
>> instructions, etc. I always felt that being able to get instructions
>> after libbpf processed them is more useful. The problem is that
>> currently libbpf frees prog->insns after successful bpf_program__load.
>> There is one extra (advanced) scenario where having those instructions
>> preserved after load would be really nice -- cloning BPF program (I
>> had use case for fentry/fexit). So the question is whether we should
>> just leave those prog->insns around until the object is closed or not?
>> And if we do, should bpftool dump instructions before or after load?
>> Let's see what folks think.
> Same here. I understand the desire, but the approach to expose half baked
> instructions isn't addressing the need.

Thanks taking the time to go trough this and understanding the use case.
You all certainly know the scope of this better than I do.
I'll study a bit more to understand how that can be achieved and try to send another patch if I find a solution.