On Mon, Nov 12, 2018 at 10:39:52AM +0100, Ard Biesheuvel wrote: > On Mon, 12 Nov 2018 at 06:31, Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > > On Mon, Nov 12, 2018 at 06:02:41AM +0100, Ingo Molnar wrote: > > > > > > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > > > > > On Fri, Nov 09, 2018 at 08:28:11AM +0100, Ingo Molnar 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. > > > > > > > > The benefit of a plugin is that we'd only need two of them: GCC and > > > > Clang. And presumably, they'd share a lot of code. > > > > > > Having looked into this, I don't think they will share any code at > all, to be honest. Perhaps some macros and string templates, that's > all.
Oh well. That should still be easier to maintain than objtool across all arches at this point. > > > > The prospect of porting objtool to all architectures is going to be much > > > > more of a daunting task (though we are at least already considering it > > > > for some arches). > > > > > > Which architectures would benefit from ORC support the most? > > > > According to my (limited and potentially flawed) knowledge, I think > > arm64 would benefit the most performance-wise, whereas powerpc and s390 > > gains would be quite a bit less. > > > > What would arm64 gain from ORC and/or objtool? Other than live patching, the biggest benefit would be an across-the-board performance improvement from disabling frame pointers. It would be interesting to see some arm64 performance numbers there, for a kernel compiled with -fomit-frame-pointer. For more details (and benefits of) ORC see Documentation/x86/orc-unwinder.txt. Objtool has also come in handy for other cases, like ensuring retpolines are used everywhere. Over time, I would like to move some objtool functionality to compiler plugins, such that it would be easier to port it to other arches. > > We may have to port objtool to arm64 anyway, for live patching. > > Is this about the reliable stack traces, i.e., the ability to detect > non-leaf functions that don't create stack frames? I think we should > be able to manage this without objtool on arm64 tbh. Hm? How else would you ensure all functions honor CONFIG_FRAME_POINTER, and continue to do so indefinitely? > > But > > that will be a lot more work than it took for Ard to write a GCC plugin. > > > > > I really think that hard reliance on GCC plugins is foolish > > > > Funny, I feel the same way about hard reliance on objtool :-) > > > > I tend to agree here. I think objtool is a necessary evil (as are > compiler plugins, for that matter) which I hope does not spread to > other architectures. I agree that it's a necessary evil, but it may be necessary on arm64 for live patching. > But the main difference is that the GCC plugin is only ~50 lines (for > this particular use case, and minus another 50 lines of boilerplate), > whereas objtool (AIUI) duplicates lots and lots of functionality of > the compiler, assembler and/or linker, to mangle relocations, create > new sections etc etc. Porting this to other architectures is going to > be a major maintenance effort, especially when I think of, e.g., > 32-bit ARM with its Thumb2 quirks and other idiosyncrasies that are > currently hidden in the toolchain. Other architectures should be first > class citizens if objtool gains support for them, which means that the > x86 people that own it currently are on the hook for testing their > changes against architectures they are not familiar with. Sounds like we could use you as a co-maintainer then :-) BTW, AFAIK, there are no plans to support live patching for 32-bit ARM. -- Josh