On Sat, Mar 13, 2021 at 11:35:36AM -0800, Andrii Nakryiko wrote: > > -$(TRUNNER_BPF_SKELS): $(TRUNNER_OUTPUT)/%.skel.h: \ > - $(TRUNNER_OUTPUT)/%.o \ > - $(BPFTOOL) \ > - | $(TRUNNER_OUTPUT) > +$(TRUNNER_BPF_SKELS): %.skel.h: %.o $(BPFTOOL) | $(TRUNNER_OUTPUT) > $$(call msg,GEN-SKEL,$(TRUNNER_BINARY),$$@) > - $(Q)$$(BPFTOOL) gen skeleton $$< > $$@ > + $(Q)$$(BPFTOOL) gen object $$(<:.o=.bpfo) $$< > + $(Q)$$(BPFTOOL) gen skeleton $$(<:.o=.bpfo) > $$@ Do we really need this .bpfo extension? bpftool in the previous patch doesn't really care about the extension. It's still a valid object file with the same ELF format. I think if we keep the same .o extension for linked .o-s it will be easier. Otherwise all loaders would need to support both .o and .bpfo, but the later is no different than the former in terms of contents of the file and ways to parse it. For testing of the linker this linked .o can be a temp file or better yet a unix pipe ? bpftool gen object - one.o second.o|bpftool gen skeleton -
