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? >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
