[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181110232059.GA12766@worktop.psav.com>
Date: Sun, 11 Nov 2018 00:20:59 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Jason Baron <jbaron@...mai.com>, Jiri Kosina <jkosina@...e.cz>,
David Laight <David.Laight@...lab.com>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH RFC 0/3] Static calls
On Fri, Nov 09, 2018 at 02:50:27PM +0100, Ard Biesheuvel wrote:
> On 9 November 2018 at 08:28, Ingo Molnar <mingo@...nel.org> wrote:
> >> - 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
I'm confused; I though we only needed objtool for variable instruction
length architectures, because we can't reliably decode our instruction
stream. Otherwise we can fairly trivially use the DWARF relocation data,
no?
Powered by blists - more mailing lists