All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Yonghong Song <yonghong.song@linux.dev>,
	bpf <bpf@vger.kernel.org>, Yonghong Song <yhs@meta.com>,
	Eduard Zingerman <eddyz87@gmail.com>,
	David Faust <david.faust@oracle.com>,
	Cupertino Miranda <cupertino.miranda@oracle.com>,
	indu.bhagat@oracle.com
Subject: Re: [PATCH bpf-next] bpf: add a few more options for GCC_BPF in selftests/bpf/Makefile
Date: Fri, 26 Apr 2024 16:41:48 +0200	[thread overview]
Message-ID: <87wmok1903.fsf@oracle.com> (raw)
In-Reply-To: <CAADnVQJJtNc=kqPby5bckOHzUFzdn_mD57c=0U7iyD23yrpKCQ@mail.gmail.com> (Alexei Starovoitov's message of "Thu, 25 Apr 2024 08:40:11 -0700")


> On Thu, Apr 25, 2024 at 5:32 AM Jose E. Marchesi
> <jose.marchesi@oracle.com> wrote:
>>
>>
>> > On Wed, Apr 24, 2024 at 2:30 PM Jose E. Marchesi
>> > <jose.marchesi@oracle.com> wrote:
>> >>
>> >>
>> >> Hi Yonghong.
>> >>
>> >> > On 4/24/24 1:41 AM, Jose E. Marchesi wrote:
>> >> >> This little patch modifies selftests/bpf/Makefile so it passes the
>> >> >> following extra options when invoking gcc-bpf:
>> >> >>
>> >> >>   -gbtf
>> >> >>     This makes GCC to emit BTF debug info in .BTF and .BTF.ext.
>> >> >
>> >> > Could we do if '-g' is specified, for bpf program,
>> >> > btf will be automatically generated?
>> >>
>> >> Hmm, in principle I wouldn't oppose for -g to mean -gbtf instead of
>> >> -gdwarf.  DWARF can always be generated by using -gdwarf.
>> >>
>> >> Faust, Indu, WDYT?
>> >>
>> >> >>
>> >> >>   -mco-re
>> >> >>     This tells GCC to generate CO-RE relocations in .BTF.ext.
>> >> >
>> >> > Can we make this default? That is, remove -mco-re option. I
>> >> > can imagine for any serious bpf program, co-re is a must.
>> >>
>> >> CO-RE depends on BTF.  So I understand the above as making -mco-re the
>> >> default if BTF is generated, i.e. if -gbtf (or -g with the modification
>> >> above) are specified.  Isn't that what clang does?  Am I interpreting
>> >> correctly?
>> >>
>> >> >>
>> >> >>   -masm=pseudoc
>> >> >>     This tells GCC to emit BPF assembler using the pseudo-c syntax.
>> >> >
>> >> > Can we make it the other way round such that -masm=pseudoc is
>> >> > the default? You can have an option e.g., -masm=non-pseudoc,
>> >> > for the other format?
>> >>
>> >> We could add a configure-time build option:
>> >>
>> >>   --with-bpf-default-asm-syntax={pseudoc,normal}
>> >>
>> >> so that GCC can be built to use whatever selected syntax as default.
>> >> Distros and people can then decide what to do.
>> >
>> > distros just ship stuff.
>> > It's our job to pick good defaults.
>>
>> Yeah it was a rather dumb idea that would only complicate things for no
>> good reason.
>>
>> The unfortunate fact is that at this point the kernel headers that
>> almost all BPF programs use contain pseudo-C inline assembly and having
>> the toolchain using the conventional assembly syntax by default would
>> force users to specify the command-line option explicitly, which is a
>> great PITA.  So I guess this is one of these situations where the worse
>> option is indeed the best default, in practical terms.
>>
>> So ok, as much as it sucks we will make -masm=pseudoc the default in GCC
>> for the sake of practicality.
>>
>> > I agree with Yonghong that -g should imply -gbtf for bpf target
>> > and -mco-re doesn't need to be a flag at all.
>>
>> We like the idea of -g implying -gbtf rather than -gdwarf for the BPF
>> target.  It makes sense.  Faust is already working on it.
>>
>> As for -mco-re, it is already the default with -gbtf, and now it will be
>> the default for -g.
>>
>> > Compiler should do it when it sees those special attributes in C code.
>> > -masm=pseudoc is a good default as well, since that's what
>> > everyone in bpf community is used to.
>>
>> We will try to get all the changes above upstream before GCC 14 gets
>> branched, which shall happen any day now.  Once they are in GCC the only
>> extra option to be added to GCC_BPF_BUILD_RULE will be -g.  Will send an
>> updated patch then.
>
> Awesome. This is all great to hear.

The GCC 14 release branch was created today, but we managed to get the
changes for -g and default to pseudo-C just in time.

  reply	other threads:[~2024-04-26 14:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24  8:41 [PATCH bpf-next] bpf: add a few more options for GCC_BPF in selftests/bpf/Makefile Jose E. Marchesi
2024-04-24 16:47 ` Eduard Zingerman
2024-04-24 21:05 ` Yonghong Song
2024-04-24 21:24   ` Jose E. Marchesi
2024-04-24 21:47     ` David Faust
2024-04-24 21:48     ` Alexei Starovoitov
2024-04-25 12:32       ` Jose E. Marchesi
2024-04-25 15:40         ` Alexei Starovoitov
2024-04-26 14:41           ` Jose E. Marchesi [this message]
2024-04-26 14:47             ` Alexei Starovoitov
2024-04-25 18:20         ` Andrii Nakryiko
2024-04-25 18:48           ` Jose E. Marchesi

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=87wmok1903.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=cupertino.miranda@oracle.com \
    --cc=david.faust@oracle.com \
    --cc=eddyz87@gmail.com \
    --cc=indu.bhagat@oracle.com \
    --cc=yhs@meta.com \
    --cc=yonghong.song@linux.dev \
    /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.