On Fri, Nov 09, 2018 at 02:50:27PM +0100, Ard Biesheuvel wrote: > On 9 November 2018 at 08:28, Ingo Molnar <mi...@kernel.org> wrote: > > > > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > >> These patches are related to two similar patch sets from Ard and Steve: > >> > >> - > >> https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheu...@linaro.org > >> - https://lkml.kernel.org/r/20181006015110.653946...@goodmis.org > >> > >> The code is also heavily inspired by the jump label code, as some of the > >> concepts are very similar. > >> > >> There are three separate implementations, depending on what the arch > >> supports: > >> > >> 1) CONFIG_HAVE_STATIC_CALL_OPTIMIZED: patched call sites - requires > >> objtool and a small amount of arch code > >> > >> 2) CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED: patched trampolines - requires > >> a small amount of arch code > >> > >> 3) If no arch support, fall back to regular function pointers > >> > >> > >> TODO: > >> > >> - I'm not sure about the objtool approach. Objtool is (currently) > >> x86-64 only, which means we have to use the "unoptimized" version > >> everywhere else. I may experiment with a GCC plugin instead. > > > > I'd prefer the objtool approach. It's a pretty reliable first-principles > > approach while GCC plugin would have to be replicated for Clang and any > > other compilers, etc. > > > > I implemented the GCC plugin approach here for arm64 > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=static-calls > > That implements both the unoptimized and the optimized versions.
Nice! That was fast :-) > I do take your point about GCC and other compilers, but on arm64 we > don't have a lot of choice. > > As far as I can tell, the GCC plugin is generic (i.e., it does not > rely on any ARM specific passes, but obviously, this requires a *lot* > of testing and validation to be taken seriously. Yeah. I haven't had a chance to try your plugin on x86 yet, but in theory it should be arch-independent. -- Josh
