From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
Martin KaFai Lau <kafai@fb.com>, David Miller <davem@redhat.com>,
John Fastabend <john.fastabend@gmail.com>,
Wenbo Zhang <ethercflow@gmail.com>,
KP Singh <kpsingh@chromium.org>, Andrii Nakryiko <andriin@fb.com>,
Brendan Gregg <bgregg@netflix.com>,
Florent Revest <revest@chromium.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v5 bpf-next 1/9] bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object
Date: Tue, 7 Jul 2020 17:43:42 +0200 [thread overview]
Message-ID: <20200707154342.GG3424581@krava> (raw)
In-Reply-To: <CAEf4BzYL=tNo9ktTkjgcSyYi-Uj3tyZ1EydKVGVTZvQBaza-Aw@mail.gmail.com>
On Mon, Jul 06, 2020 at 05:34:52PM -0700, Andrii Nakryiko wrote:
SNIP
> > +$(OUTPUT)rbtree.o: ../../lib/rbtree.c FORCE
> > + $(call rule_mkdir)
> > + $(call if_changed_dep,cc_o_c)
> > +
> > +$(OUTPUT)zalloc.o: ../../lib/zalloc.c FORCE
> > + $(call rule_mkdir)
> > + $(call if_changed_dep,cc_o_c)
> > +
> > +$(OUTPUT)string.o: ../../lib/string.c FORCE
> > + $(call rule_mkdir)
> > + $(call if_changed_dep,cc_o_c)
> > +
> > +$(OUTPUT)ctype.o: ../../lib/ctype.c FORCE
> > + $(call rule_mkdir)
> > + $(call if_changed_dep,cc_o_c)
> > +
> > +$(OUTPUT)str_error_r.o: ../../lib/str_error_r.c FORCE
> > + $(call rule_mkdir)
> > + $(call if_changed_dep,cc_o_c)
>
> Is Build also a Makefile? If that's the case, why not:
>
> $(output)%.o: ../../lib/%.c FORCE
> $(call rule_mkdir)
> $(call if_changed_dep,cc_o_c)
hum, it is ... I'll try that
>
> ?
>
> > diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> > new file mode 100644
> > index 000000000000..948378ca73d4
> > --- /dev/null
> > +++ b/tools/bpf/resolve_btfids/Makefile
> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +include ../../scripts/Makefile.include
> > +
> > +ifeq ($(srctree),)
> > +srctree := $(patsubst %/,%,$(dir $(CURDIR)))
> > +srctree := $(patsubst %/,%,$(dir $(srctree)))
> > +srctree := $(patsubst %/,%,$(dir $(srctree)))
> > +endif
> > +
> > +ifeq ($(V),1)
> > + Q =
> > + msg =
> > +else
> > + Q = @
> > + msg = @printf ' %-8s %s%s\n' "$(1)" "$(notdir $(2))" "$(if $(3), $(3))";
> > + MAKEFLAGS=--no-print-directory
> > +endif
> > +
> > +OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
>
> Ok, so this builds nicely for in-tree build, but when I did
> out-of-tree build (I use KBUILD_OUTPUT, haven't checked specifying
> O=whatever), I get:
>
> LD vmlinux
> BTFIDS vmlinux
> /data/users/andriin/linux/scripts/link-vmlinux.sh: line 342:
> /data/users/andriin/linux/tools/bpf/resolve_btfids/resolve_btfids: No
> such file or directory
>
> I suspect because you are assuming OUTPUT to be in srctree? You
> probably need to adjust for out-of-tree mode.
ok, make clean did not clean resolve_btfids, so it was
still there when I tried the out of the tree build..
>
> > +
> > +LIBBPF_SRC := $(srctree)/tools/lib/bpf/
> > +SUBCMD_SRC := $(srctree)/tools/lib/subcmd/
> > +
> > +BPFOBJ := $(OUTPUT)/libbpf.a
> > +SUBCMDOBJ := $(OUTPUT)/libsubcmd.a
>
> [...]
>
> > +
> > +#define BTF_IDS_SECTION ".BTF.ids"
>
> You haven't updated a bunch of places (cover letter, this patch commit
> message, maybe somewhere else) after renaming from .BTF_ids, please
> keep them in sync. Also, while I'm not too strongly against this name,
> it does sound like this section is part of generic BTF format (as is
> .BTF and .BTF.ext), which it is not, because it's so kernel-specific.
> So I'm mildly against it and pro .BTF_ids.
.BTF_ids it is.. I'll change all the places
>
> > +#define BTF_ID "__BTF_ID__"
> > +
> > +#define BTF_STRUCT "struct"
> > +#define BTF_UNION "union"
> > +#define BTF_TYPEDEF "typedef"
> > +#define BTF_FUNC "func"
> > +#define BTF_SET "set"
> > +
>
> [...]
>
> > +}
> > +
> > +static struct btf *btf__parse_raw(const char *file)
>
> I thought you were going to add this to libbpf itself? Or you planned
> to do a follow up patch later?
yes, I did not want to complicate this patchset more,
and send this change after.. also then there'll be one
more reason to make it a library function ;-)
thanks,
jirka
next prev parent reply other threads:[~2020-07-07 15:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 9:51 [PATCH v5 bpf-next 0/9] bpf: Add d_path helper - preparation changes Jiri Olsa
2020-07-03 9:51 ` [PATCH v5 bpf-next 1/9] bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object Jiri Olsa
2020-07-07 0:34 ` Andrii Nakryiko
2020-07-07 15:43 ` Jiri Olsa [this message]
2020-07-03 9:51 ` [PATCH v5 bpf-next 2/9] bpf: Compile resolve_btfids tool at kernel compilation start Jiri Olsa
2020-07-03 9:51 ` [PATCH v5 bpf-next 3/9] bpf: Add BTF_ID_LIST/BTF_ID/BTF_ID_UNUSED macros Jiri Olsa
2020-07-03 9:51 ` [PATCH v5 bpf-next 4/9] bpf: Resolve BTF IDs in vmlinux image Jiri Olsa
2020-07-07 0:38 ` Andrii Nakryiko
2020-07-07 15:35 ` Jiri Olsa
2020-07-03 9:51 ` [PATCH v5 bpf-next 5/9] bpf: Remove btf_id helpers resolving Jiri Olsa
2020-07-07 0:46 ` Andrii Nakryiko
2020-07-03 9:51 ` [PATCH v5 bpf-next 6/9] bpf: Use BTF_ID to resolve bpf_ctx_convert struct Jiri Olsa
2020-07-07 0:47 ` Andrii Nakryiko
2020-07-03 9:51 ` [PATCH v5 bpf-next 7/9] bpf: Add info about .BTF.ids section to btf.rst Jiri Olsa
2020-07-03 9:51 ` [PATCH v5 bpf-next 8/9] tools headers: Adopt verbatim copy of btf_ids.h from kernel sources Jiri Olsa
2020-07-07 0:56 ` Andrii Nakryiko
2020-07-07 15:44 ` Jiri Olsa
2020-07-03 9:51 ` [PATCH v5 bpf-next 9/9] selftests/bpf: Add test for resolve_btfids Jiri Olsa
2020-07-07 1:26 ` Andrii Nakryiko
2020-07-07 15:57 ` Jiri Olsa
2020-07-07 17:49 ` Andrii Nakryiko
2020-07-08 21:18 ` Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200707154342.GG3424581@krava \
--to=jolsa@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bgregg@netflix.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@redhat.com \
--cc=ethercflow@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=revest@chromium.org \
--cc=songliubraving@fb.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.