On 2015/5/28 16: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?
>
This proposal sounds good to me, and I look forward to it be merged soon:)
Then I'll make the appropriate changes in kernel.
Thanks!
Li Bin
> 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
>
>
>
>
>
