BPF List
 help / color / mirror / Atom feed
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: daniel@iogearbox.net, alexei.starovoitov@gmail.com, bpf@vger.kernel.org
Subject: Re: EF_BPF_GNU_XBPF
Date: Thu, 03 Sep 2020 01:40:10 +0200	[thread overview]
Message-ID: <87blin21et.fsf@oracle.com> (raw)
In-Reply-To: <20200902.162222.1706338150182336333.davem@davemloft.net> (David Miller's message of "Wed, 02 Sep 2020 16:22:22 -0700 (PDT)")


>> 1) Due to BPF being so restrictive, many hundreds of GCC tests won't
>>    even build, because they use functions having more than 5 arguments,
>>    or functions with too big stack frames, or indirect calls, etc.  We
>>    want to be able to test our backend properly, so we added the -mxbpf
>>    option in order to relax some of these restrictions.
>> 
>> 2) We are working on a BPF simulator that works with GDB.  For that to
>>    work, we needed to add a "breakpoint" instruction that GDB can patch
>>    in the program.  Having a simulator also allows us to run more GCC
>>    tests.
>> 
>> 3) With some extensions, it becomes possible to support DWARF call frame
>>    information, and therefore to debug BPF programs in GDB with
>>    unwinding support.  You can build with -mxbpf, debug, then build
>>    again without -mxbpf.
>
> All sounds like features to propose for BPF itself, rather than throw
> into some weird extension.
>
> Why not come to the bpf community and discuss the need for these
> features?

Well, as I said these features are mainly intended for the benefit of
the tooling side.  But of course if some of them are deemed useful
enough (and feasible) to be added to BPF proper, then great!

As for discussion, here I am, as I was in LPC :)

  reply	other threads:[~2020-09-02 23:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 18:18 EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 19:31 ` EF_BPF_GNU_XBPF Alexei Starovoitov
2020-09-02 20:19   ` EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 20:32     ` EF_BPF_GNU_XBPF Alexei Starovoitov
2020-09-02 21:17       ` EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 21:33         ` EF_BPF_GNU_XBPF Daniel Borkmann
2020-09-02 22:10           ` EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 23:22             ` EF_BPF_GNU_XBPF David Miller
2020-09-02 23:40               ` Jose E. Marchesi [this message]
2020-09-02 23:20           ` EF_BPF_GNU_XBPF David Miller
2020-09-02 23:18       ` EF_BPF_GNU_XBPF David Miller
2020-09-02 23:27         ` EF_BPF_GNU_XBPF 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=87blin21et.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    /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