bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Slava Bacherikov <slava@bacher09.org>
Cc: Kees Cook <keescook@chromium.org>,
	Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Jann Horn <jannh@google.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Liu Yiding <liuyd.fnst@cn.fujitsu.com>,
	KP Singh <kpsingh@google.com>
Subject: Re: [PATCH v3 bpf] kbuild: fix dependencies for DEBUG_INFO_BTF
Date: Wed, 1 Apr 2020 10:46:57 -0700	[thread overview]
Message-ID: <CAEf4BzYx7hffHm5RV3QQQqvgAzy-41DRgFQDKh+4xcM9OL890A@mail.gmail.com> (raw)
In-Reply-To: <eba80d4e-a385-1fba-37f9-38888ae91f1e@bacher09.org>

On Wed, Apr 1, 2020 at 7:38 AM Slava Bacherikov <slava@bacher09.org> wrote:
>
>
>
> 01.04.2020 17:20, Slava Bacherikov wrotes:
> > Currently turning on DEBUG_INFO_SPLIT when DEBUG_INFO_BTF is also
> > enabled will produce invalid btf file, since gen_btf function in
> > link-vmlinux.sh script doesn't handle *.dwo files.
> >
> > Enabling DEBUG_INFO_REDUCED will also produce invalid btf file, and
> > using GCC_PLUGIN_RANDSTRUCT with BTF makes no sense.
> >
> > Signed-off-by: Slava Bacherikov <slava@bacher09.org>
> > Reported-by: Jann Horn <jannh@google.com>
> > Reported-by: Liu Yiding <liuyd.fnst@cn.fujitsu.com>
> > Acked-by: KP Singh <kpsingh@google.com>
> > Acked-by: Andrii Nakryiko <andriin@fb.com>
> > Fixes: e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")
> > ---
> >  lib/Kconfig.debug | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index f61d834e02fe..b94227be2d62 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -222,7 +222,9 @@ config DEBUG_INFO_DWARF4
> >
> >  config DEBUG_INFO_BTF
> >       bool "Generate BTF typeinfo"
> > -     depends on DEBUG_INFO
> > +     depends on DEBUG_INFO || COMPILE_TEST
> I had to add this, since DEBUG_INFO which depends on:
>
>         DEBUG_KERNEL && !COMPILE_TEST
>
> would block DEBUG_INFO_BTF when COMPILE_TEST is turned on.
>

Sorry if I'm being dense here. But what's the point in enabling
DEBUG_INFO_BTF if there is no *valid* DWARF info available for
DWARF-to-BTF conversion?


> In that case allyesconfig will emit both:
>
> CONFIG_DEBUG_INFO_BTF=y
> CONFIG_GCC_PLUGIN_RANDSTRUCT=y

Which I thought is exactly what we wanted to avoid. Not sure what's
the point of compiling kernel (even if it's the one that is not
supposed to ever run) that apriori has broken BTF? If it was
acceptable to not have DEBUG_INFO for COMPILE_TEST, why it's not
acceptable to not have DEBUG_INFO_BTF in that situation as well?

>
>
>
> > +     depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
> > +     depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> >       help
> >         Generate deduplicated BTF type information from DWARF debug info.
> >         Turning this on expects presence of pahole tool, which will convert
> >

  reply	other threads:[~2020-04-01 17:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 21:55 [PATCH v2 bpf] kbuild: fix dependencies for DEBUG_INFO_BTF Slava Bacherikov
2020-03-31 22:40 ` KP Singh
2020-04-01  0:03 ` Andrii Nakryiko
2020-04-01  7:34 ` Kees Cook
2020-04-01 14:20   ` [PATCH v3 " Slava Bacherikov
2020-04-01 14:37     ` Slava Bacherikov
2020-04-01 17:46       ` Andrii Nakryiko [this message]
2020-04-01 18:24         ` Slava Bacherikov
2020-04-01 15:49     ` Kees Cook
2020-04-02 15:33       ` [PATCH v4 " Slava Bacherikov
2020-04-02 15:40         ` Slava Bacherikov
2020-04-02 19:31           ` Andrii Nakryiko
2020-04-02 20:34             ` Kees Cook
2020-04-02 20:38               ` Slava Bacherikov
2020-04-02 20:41               ` [PATCH v5 " Slava Bacherikov
2020-04-02 21:02                 ` Andrii Nakryiko
2020-04-02 22:49                 ` Daniel Borkmann

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=CAEf4BzYx7hffHm5RV3QQQqvgAzy-41DRgFQDKh+4xcM9OL890A@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kpsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuyd.fnst@cn.fujitsu.com \
    --cc=slava@bacher09.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;
as well as URLs for NNTP newsgroup(s).