From: Peter Zijlstra <peterz@infradead.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: linux-toolchains@vger.kernel.org,
clang-built-linux <clang-built-linux@googlegroups.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Kees Cook <keescook@chromium.org>,
Florian Weimer <fweimer@redhat.com>,
Christian Brauner <christian.brauner@canonical.com>,
nick.alcock@oracle.com,
Segher Boessenkool <segher@kernel.crashing.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Will Deacon <will@kernel.org>,
andrew.cooper3@citrix.com
Subject: Re: Plumbers CF MCs
Date: Tue, 23 Mar 2021 09:35:10 +0100 [thread overview]
Message-ID: <YFmoPpb5w4q1dWXz@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKwvOdndc=ej=40WktFz0t083pZJcdX1tipuWoTvAw=JC8b3Aw@mail.gmail.com>
On Mon, Mar 22, 2021 at 01:23:03PM -0700, Nick Desaulniers wrote:
> Hi all,
> I saw plumbers opened call for microconferences:
> https://www.linuxplumbersconf.org/blog/2021/index.php/2021/03/18/cfp-open-microconferences/
>
> I was going to put together a submission; do we want to do a combined
> toolchain MC, or have distinct ones this year?
>
> I know in 2020 the GNU cauldron was co-located with Plumbers, as well
> as a GNU Tools Track MC and LLVM MC.
A combined MC focussed on kernel issues seems very interesting. We still
have the control dependency (volatile-if?) thing pending. We had a bit
of a discussion on that after last year, but I don't think anything
really came of that, can we pick that up? Ideally a compiler person does
an actual proposal for this year.
If we can sort that, there's the rest of the dependencies Will outlined
:-)
Then there seemed to be people that thought __always_inline was a
suggestion... I think we need to explore how that was ever possible.
There's the endless UB debate... can we define more to reduce the UB? I
mean, we're already bound by architecture ABI on the one hand, and
actual use on the other. It would be so very nice to be able to get more
-fwrapv and -fno-strict-aliasing knobs that define UBs away.
There also is talk about straight line speculation mitigations. for x86
we should probably emit an INT3 after every JMP and RET. Although this
might not be controversial and be sorted by the time Plumbers happens.
There was some talk about how compilers could help objtool make sense of
jump tables.
GCC's status on asm-goto with outputs?
Clang's getting asm-constraints wrong ("rm" and it always picks "m").
And I'm sure there was more..
next prev parent reply other threads:[~2021-03-23 8:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 20:23 Plumbers CF MCs Nick Desaulniers
2021-03-22 20:39 ` Jose E. Marchesi
2021-03-31 19:34 ` Elena Zannoni
2021-03-31 20:36 ` Nick Desaulniers
2021-04-01 7:59 ` Jose E. Marchesi
2021-04-01 20:01 ` Nick Desaulniers
2021-04-01 13:29 ` Steven Rostedt
2021-04-01 13:31 ` Steven Rostedt
2021-04-01 13:49 ` Elena Zannoni
2021-04-01 15:11 ` Miguel Ojeda
2021-04-01 20:11 ` Nick Desaulniers
2021-04-01 13:25 ` Steven Rostedt
2021-04-01 13:25 ` Steven Rostedt
2021-03-23 8:35 ` Peter Zijlstra [this message]
2021-03-23 8:45 ` Peter Zijlstra
2021-03-23 19:29 ` Andrew Cooper
2021-03-23 19:53 ` Peter Zijlstra
2021-03-23 22:12 ` Peter Zijlstra
2021-03-24 0:36 ` Steven Rostedt
2021-03-24 8:15 ` Peter Zijlstra
2021-03-23 22:23 ` Andrew Cooper
2021-03-24 8:08 ` Peter Zijlstra
2021-03-24 11:30 ` Andrew Cooper
2021-04-02 12:40 ` Segher Boessenkool
2021-03-23 22:26 ` Nick Desaulniers
2021-03-24 7:52 ` Peter Zijlstra
2021-03-24 8:47 ` Christian Brauner
2021-03-30 14:13 ` Will Deacon
2021-04-01 7:17 ` Kees Cook
2021-04-02 12:33 ` Segher Boessenkool
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=YFmoPpb5w4q1dWXz@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrew.cooper3@citrix.com \
--cc=christian.brauner@canonical.com \
--cc=clang-built-linux@googlegroups.com \
--cc=fweimer@redhat.com \
--cc=jemarch@gnu.org \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=ndesaulniers@google.com \
--cc=nick.alcock@oracle.com \
--cc=rostedt@goodmis.org \
--cc=segher@kernel.crashing.org \
--cc=will@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