This is the mail archive of the
mailing list for the GCC project.
Re: arm64:, Re: [RFC] Kernel livepatching support in GCC
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: AKASHI Takahiro <takahiro dot akashi at linaro dot org>, 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 11:23:22 +0100
- 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> <5629F9A7 dot 3040808 at linaro dot org>
On 23/10/15 10:11, AKASHI Takahiro wrote:
On 10/22/2015 07:26 PM, Szabolcs Nagy wrote:
On 22/10/15 11:14, AKASHI Takahiro wrote:
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.
ok, i may be confused.
i thought there is a static ftrace (functions are
instrumented with mcount using -pg) and a dynamic one
where the code is modified at runtime.
then i thought adding -fprolog-pad=N would be good for the
dynamic case, but not for the static case.
the static case may need improvements too because the
current way (using regular c call abi for mcount) affects
code generation more significantly than the proposed
-mfentry solution would (e.g. leaf functions turn into
hence the question: is the kernel satisfied with -pg mcount
for the static ftrace or does it want -mfentry behaviour