Hi, The feedback in this thread was overall positive with good suggestions on implementation details. I'm starting to work on the first draft, and plan to post something in 2-4 weeks.
Thanks. On 28 May 2015 at 11:39, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> wrote: > Hi, > > Akashi-san and I have been discussing required GCC changes to make kernel's > livepatching work for AArch64 and other architectures. At the moment > livepatching is supported for x86[_64] using the following options: "-pg > -mfentry -mrecord-mcount -mnop-mcount" which is geek-speak for "please add > several NOPs at the very beginning of each function, and make a section with > addresses of all those NOP pads". > > The above long-ish list of options is a historical artifact of how > livepatching support evolved for x86. The end result is that for > livepatching (or ftrace, or possible future kernel features) to work compiler > needs to generate a little bit of empty code space at the beginning of each > function. Kernel can later use that space to insert call sequences for > various hooks. > > Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount > options to other architectures, we should implement a target-independent > option -fprolog-pad=N, which will generate a pad of N nops at the beginning > of each function and add a section entry describing the pad similar to > -mrecord-mcount [1]. > > Since adding NOPs is much less architecture-specific then outputting call > instruction sequences, this option can be handled in a target-independent way > at least for some/most architectures. > > Comments? > > As I found out today, the team from Huawei has implemented [2], which follows > x86 example of -mfentry option generating a hard-coded call sequence. I hope > that this proposal can be easily incorporated into their work since most of > the livepatching changes are in the kernel. > > [1] Technically, generating a NOP pad and adding a section entry in > .__mcount_loc are two separate actions, so we may want to have a > -fprolog-pad-record option. My instinct is to stick with a single option for > now, since we can always add more later. > > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346905.html > > -- > Maxim Kuvyrkov > www.linaro.org > > > -- Maxim Kuvyrkov www.linaro.org
