From: Yonghong Song <yhs@fb.com>
To: "Jörn-Thorben Hinz" <jthinz@mailbox.tu-berlin.de>, bpf@vger.kernel.org
Cc: Quentin Monnet <quentin@isovalent.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>
Subject: Re: [RFC PATCH bpf-next] bpftool: Mark generated skeleton headers as system headers
Date: Thu, 28 Jul 2022 11:25:53 -0700 [thread overview]
Message-ID: <7d4af6b4-f4da-f004-48a1-e408d8615ee8@fb.com> (raw)
In-Reply-To: <20220728165644.660530-1-jthinz@mailbox.tu-berlin.de>
On 7/28/22 9:56 AM, Jörn-Thorben Hinz wrote:
> Hi,
>
> after compiling a skeleton-using program with -pedantic once and
> stumbling across a tiniest incorrectness in skeletons with it[1], I was
> debating whether it makes sense to suppress warnings from skeleton
> headers.
>
> Happy about comments about this. This change might be too suppressive
> towards warnings and maybe ignoring only -Woverlength-strings directly
> in OBJ_NAME__elf_bytes() be a better idea. Or keep all warnings from
> skeletons available as-is to have them more visible in and around
> bpftool’s development.
This is my 2cents. As you mentioned, skeleton file are per program
and not in system header file directory. I would like not to mark
these header files as system files. Since different program will
generate different skeleton headers, suppressing warnings
will prevent from catching potential issues in certain cases.
Also, since the warning is triggered by extra user flags like -pedantic
when building bpftool, user can also add -Wno-overlength-strings
in the extra user flags.
>
> [1] https://lore.kernel.org/r/20220726133203.514087-1-jthinz@mailbox.tu-berlin.de/
>
> Commit message:
>
> A userspace program including a skeleton generated by bpftool might use
> an arbitrary set of compiler flags, including enabling various warnings.
>
> For example, with -Woverlength-strings the string constant in
> OBJ_NAME__elf_bytes() causes a warning due to its usually huge length.
> This string length is not an actual problem with GCC and clang, though,
> it’s “just” not required by the C standard to be supported.
>
> Skeleton headers are likely not placed in a system include path. To
> avoid the above warning and similar noise for the *user* of a skeleton,
> explicitly mark the header as a system header which disables almost all
> warnings for it when included.
>
> Skeleton headers generated during the build of bpftool are not marked to
> keep potential warnings available to bpftool’s developers.
>
> Signed-off-by: Jörn-Thorben Hinz <jthinz@mailbox.tu-berlin.de>
> ---
> tools/bpf/bpftool/Makefile | 2 ++
> tools/bpf/bpftool/gen.c | 30 +++++++++++++++++++++++++++---
> 2 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 6b5b3a99f79d..5f484d7929db 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -196,6 +196,8 @@ endif
>
> CFLAGS += $(if $(BUILD_BPF_SKELS),,-DBPFTOOL_WITHOUT_SKELETONS)
>
> +$(BOOTSTRAP_OUTPUT)%.o: CFLAGS += -DBPFTOOL_BOOTSTRAP
> +
> $(BOOTSTRAP_OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
> $(QUIET_CC)$(HOSTCC) $(HOST_CFLAGS) -c -MMD $< -o $@
>
> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index 1cf53bb01936..82053aceec78 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c
> @@ -1006,7 +1006,15 @@ static int do_skeleton(int argc, char **argv)
> /* THIS FILE IS AUTOGENERATED BY BPFTOOL! */ \n\
> #ifndef %2$s \n\
> #define %2$s \n\
> - \n\
> + "
> +#ifndef BPFTOOL_BOOTSTRAP
> + "\
> + \n\
> + _Pragma(\"GCC system_header\") \n\
> + "
> +#endif
> + "\
> + \n\
> #include <bpf/skel_internal.h> \n\
> \n\
> struct %1$s { \n\
> @@ -1022,7 +1030,15 @@ static int do_skeleton(int argc, char **argv)
> /* THIS FILE IS AUTOGENERATED BY BPFTOOL! */ \n\
> #ifndef %2$s \n\
> #define %2$s \n\
> - \n\
> + "
> +#ifndef BPFTOOL_BOOTSTRAP
> + "\
> + \n\
> + _Pragma(\"GCC system_header\") \n\
> + "
> +#endif
> + "\
> + \n\
> #include <errno.h> \n\
> #include <stdlib.h> \n\
> #include <bpf/libbpf.h> \n\
> @@ -1415,7 +1431,15 @@ static int do_subskeleton(int argc, char **argv)
> /* THIS FILE IS AUTOGENERATED! */ \n\
> #ifndef %2$s \n\
> #define %2$s \n\
> - \n\
> + "
> +#ifndef BPFTOOL_BOOTSTRAP
> + "\
> + \n\
> + _Pragma(\"GCC system_header\") \n\
> + "
> +#endif
> + "\
> + \n\
> #include <errno.h> \n\
> #include <stdlib.h> \n\
> #include <bpf/libbpf.h> \n\
next prev parent reply other threads:[~2022-07-28 18:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 16:56 [RFC PATCH bpf-next] bpftool: Mark generated skeleton headers as system headers Jörn-Thorben Hinz
2022-07-28 18:25 ` Yonghong Song [this message]
2022-07-29 10:12 ` Quentin Monnet
2022-07-29 17:06 ` Yonghong Song
2022-07-29 17:29 ` Jörn-Thorben Hinz
2022-07-29 17:29 ` Jörn-Thorben Hinz
2022-08-02 23:16 ` Yonghong Song
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=7d4af6b4-f4da-f004-48a1-e408d8615ee8@fb.com \
--to=yhs@fb.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=jthinz@mailbox.tu-berlin.de \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=quentin@isovalent.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox