[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210317053437.r5zsoksdqrxtt22r@ast-mbp>
Date: Tue, 16 Mar 2021 22:34:37 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Andrii Nakryiko <andrii@...nel.org>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...com,
daniel@...earbox.net, kernel-team@...com
Subject: Re: [PATCH v2 bpf-next 10/11] selftests/bpf: pass all BPF .o's
through BPF static linker
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 -
Powered by blists - more mailing lists