On Thu, Jul 15, 2021 at 2:40 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Tue, Jul 13, 2021 at 11:34 AM Lorenzo Fontana > <fontanalorenz@xxxxxxxxx> 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.
