On 28/05/15 10:39, Maxim Kuvyrkov 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? >
Rather than just a sequence of NOP's, should the first NOP be a unconditional branch to the beginning of the real function? I don't know if this applies to AArch64 cpus, but I believe some cpus can handle such branches already in the decode unit, thus avoiding any extra cycles for skipping the NOPs. David
