Li,
(added linux-arm-kernel to Cc.)

On 10/22/2015 06:07 PM, libin wrote:


在 2015/5/28 16:39, Maxim Kuvyrkov 写道:
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.


Thanks very much for your effort for this, and the arch-independed 
implementation
is very good to me, but only have one question that how to enture the atomic
replacement of multi instructions in kernel side?

I have one idea, but we'd better discuss this topic in, at least including, 
linux-arm-kernel.

And before this arch-independed option, can we consider the arch-depended 
-mfentry
implemention for arm64 like arch x86 firstly? I will post it soon.

livepatch for arm64 based on this arm64 -mfentry feature on github:
https://github.com/libin2015/livepatch-for-arm64.git  master


I also have my own version of livepatch support for arm64 using yet-coming 
"-fprolog-add=N" option :)
As we discussed before, the main difference will be how we should preserve LR 
register when invoking
a ftrace hook (ftrace_regs_caller).
But again, this is a topic to discuss mainly in linux-arm-kernel.
(I have no intention of excluding gcc ml from the discussions.)

Thanks,
-Takahiro AKASHI

discussions on this topic:
https://lkml.org/lkml/2015/5/28/54

Thanks,
Li Bin

[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






Reply via email to