> On May 28, 2015, at 11:59 AM, Richard Biener <richard.guent...@gmail.com> > wrote: > > On May 28, 2015 10:39:27 AM GMT+02:00, 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? > > Maybe follow s390 -mhotpatch instead?
Regarding implementation of the option, it will follow what s390 is doing with function attributes to mark which functions to apply nop-treatment to (using attributes will avoid problems with [coming] LTO builds of the kernel). The new option will set value of the attribute on all functions in current compilation unit, and then nops will be generated from the attribute specification. On the other hand, s390 does not generate a section of descriptor entries of NOP pads, which seems like a useful (or necessary) option. A more-or-less generic implementation should, therefore, combine s390's attributes approach to annotating functions and x86's approach to providing information in an ELF section about NOP entries. Or can we record value of a function attribute in ELF in a generic way? Whatever the specifics, implementation of livepatch support should be decoupled from -pg/mcount dependency as I don't see any real need in overloading mcount with livepatching stuff. -- Maxim Kuvyrkov www.linaro.org
