This is the mail archive of the
mailing list for the GCC project.
Re: arm64:, Re: [RFC] Kernel livepatching support in GCC
- From: AKASHI Takahiro <takahiro dot akashi at linaro dot org>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, libin <huawei dot libin at huawei dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Andi Kleen <ak at linux dot intel dot com>, Geoff Levand <Geoff dot Levand at huawei dot com>, Andrew dot Wafaa at arm dot com, Seth Jennings <sjenning at redhat dot com>, jpoimboe at redhat dot com, jkosina at suse dot cz, huxinwei at huawei dot com, Hanjun Guo <guohanjun at huawei dot com>, Xie XiuQi <xiexiuqi at huawei dot com>, felix dot yang at huawei dot com, jiangjiji at huawei dot com, "broonie at kernel dot org" <broonie at kernel dot org>, "linux-arm-kernel at lists dot infradead dot org" <linux-arm-kernel at lists dot infradead dot org>
- Date: Fri, 23 Oct 2015 18:11:03 +0900
- Subject: Re: arm64:, Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org> <5628A738 dot 5000305 at huawei dot com> <5628B704 dot 8070608 at linaro dot org> <5628B9D4 dot 9020701 at arm dot com>
On 10/22/2015 07:26 PM, Szabolcs Nagy wrote:
On 22/10/15 11:14, AKASHI Takahiro wrote:
On 10/22/2015 06:07 PM, libin wrote:
å 2015/5/28 16:39, Maxim Kuvyrkov åé:
Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount options to other architectures,
implement a target-independent option -fprolog-pad=N, which will generate a pad of N nops at the beginning
function and add a section entry describing the pad similar to -mrecord-mcount .
Since adding NOPs is much less architecture-specific then outputting call instruction sequences, this option
handled in a target-independent way at least for some/most architectures.
As I found out today, the team from Huawei has implemented , 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
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:
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.)
is -fprolog-add=N enough from gcc?
Yes, as far as I correctly understand this option.
i assume it solves the live patching, but i thought -mfentry
might be still necessary when live patching is not used.
- Livepatch depends on ftrace's DYNAMIC_FTRACE_WITH_REGS feature
- DYNAMIC_FTRACE_WITH_REGS can be implemented either with -fprolog-add=N or -mfentry
- x86 is the only architecture that supports -mfentry AFAIK
- and it is used in the kernel solely to implement this ftrace feature AFAIK
- So once a generic option, fprolog-add=N, is supported, we have no reason to add arch-specific -mfentry.
or is the kernel fine with the current mcount abi for that?
(note that changes the code generation in leaf functions
Can you please elaborate your comments in more details?
I didn't get your point here.
and currently the kernel relies on frame pointers etc.)