[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201118191127.GM2672@gate.crashing.org>
Date: Wed, 18 Nov 2020 13:11:27 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Florian Weimer <fw@...eb.enyo.de>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Matt Mullins <mmullins@...x.us>,
Ingo Molnar <mingo@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Dmitry Vyukov <dvyukov@...gle.com>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>,
netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
linux-toolchains@...r.kernel.org
Subject: Re: violating function pointer signature
On Wed, Nov 18, 2020 at 01:58:23PM -0500, Steven Rostedt wrote:
> I wonder if we should define on all architectures a void void_stub(void),
> in assembly, that just does a return, an not worry about gcc messing up the
> creation of the stub function.
>
> On x86_64:
>
> GLOBAL(void_stub)
> retq
>
>
> And so on.
I don't see how you imagine a compiler to mess this up?
void void_stub(void) { }
will do fine?
.globl void_stub
.type void_stub, @function
void_stub:
.LFB0:
.cfi_startproc
ret
.cfi_endproc
.LFE0:
.size void_stub, .-void_stub
Calling this via a different declared function type is undefined
behaviour, but that is independent of how the function is *defined*.
Your program can make ducks appear from your nose even if that function
is never called, if you do that. Just don't do UB, not even once!
Segher
Powered by blists - more mailing lists