On Fri, 2022-03-11 at 15:40 -0800, Andrii Nakryiko wrote: > > we shouldn't need or use name for subskeleton (in real life you won't > know the name of the final bpf_object) Let's have this discussion in the bpftool email thread. Happy to remove the name in the Makefile and fall back on the filename though. > > > > $(TRUNNER_BPF_LSKELS): %.lskel.h: %.o $(BPFTOOL) | $(TRUNNER_OUTPUT) > > $$(call msg,GEN-SKEL,$(TRUNNER_BINARY),$$@) > > @@ -421,6 +428,7 @@ $(TRUNNER_BPF_SKELS_LINKED): $(TRUNNER_BPF_OBJS) $(BPFTOOL) | $(TRUNNER_OUTPUT) > > $(Q)diff $$(@:.skel.h=.linked2.o) $$(@:.skel.h=.linked3.o) > > $$(call msg,GEN-SKEL,$(TRUNNER_BINARY),$$@) > > $(Q)$$(BPFTOOL) gen skeleton $$(@:.skel.h=.linked3.o) name $$(notdir $$(@:.skel.h=)) > $$@ > > + $(Q)$$(BPFTOOL) gen subskeleton $$(@:.skel.h=.linked3.o) name $$(notdir $$(@:.skel.h=)) > $$(@:.skel.h=.subskel.h) > > probably don't need subskel for LSKELS (and it just adds race when we > generate both skeleton and light skeleton for the same object file) We're not generating subskels for LSKELS, that's just confusing diff output. This is under the $(TRUNNER_BPF_SKELS_LINKED) outputs. > > can you please add CONFIG_BPF_SYSCALL here as well, to check that > externs are properly "merged" and found, even if they overlap between > library and app BPF code Sure. > > libbpf supports .data.my_custom_name and .rodata.my_custom_whatever, > let's have a variable to test this also works? Sure. > > let's move this into progs/test_subskeleton.c instead. It will > simulate a bit more complicated scenario, where library expects > application to define and provide a map, but the library itself > doesn't define it. It should work just fine right now (I think), but > just in case let's double check that having only "extern map" in the > library works. This fails to even open in bpftool: libbpf: map 'map2': unsupported map linkage extern. Error: failed to open BPF object file: Operation not supported If we think this is valuable enough to support, let's tackle it separately after the bulk of this functionality is merged? -- Delyan
