On Sun, Apr 18, 2021 at 3:57 PM Andy Lutomirski <l...@kernel.org> wrote: > > On Sun, Apr 18, 2021 at 9:17 AM Thomas Gleixner <t...@linutronix.de> wrote: > > > > On Sat, Apr 17 2021 at 17:11, Andy Lutomirski wrote: > > > On Sat, Apr 17, 2021 at 4:53 PM Thomas Gleixner <t...@linutronix.de> > > > wrote: > > >> which works for > > >> > > >> foo = function_nocfi(bar); > > > > > > I agree in general. But right now, we have, in asm/proto.h: > > > > > > void entry_SYSCALL_64(void); > > > > > > and that's pure nonsense. Depending on your point of view, > > > entry_SYSCALL_64 is a symbol that resolves to an integer or it's an > > > array of bytes containing instructions, but it is most definitely not > > > a function void (void). So, regardless of any CFI stuff, I propose > > > that we standardize our handling of prototypes of symbols that are > > > opaque to the C compiler. Here are a couple of choices: > > > > > > Easy one: > > > > > > extern u8 entry_SYSCALL_64[]; > > > > > > Slightly more complicated: > > > > > > struct opaque_symbol; > > > extern struct opaque_symbol entry_SYSCALL_64; > > > > > > The opaque_symbol variant avoids any possible confusion over the weird > > > status of arrays in C, and it's hard to misuse, since struct > > > opaque_symbol is an incomplete type. > > > > Makes sense. > > Sami, do you want to do this as part of your series or should I write a patch?
I can certainly include this in the next version, but that might have to wait a bit for compiler changes, so if you want this done sooner, please go ahead. Sami
