On 7/16/21 3:51 AM, Alexei Starovoitov wrote: > 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. 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.
