This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Kernel livepatching support in GCC
- From: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Cc: Li Bin <huawei dot libin at huawei dot com>, Andi Kleen <ak at linux dot intel dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Richard Biener <richard dot guenther at gmail dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Tue, 13 Oct 2015 15:51:12 +0300
- Subject: Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org>
Hi,
The feedback in this thread was overall positive with good suggestions
on implementation details. I'm starting to work on the first draft,
and plan to post something in 2-4 weeks.
Thanks.
On 28 May 2015 at 11:39, Maxim Kuvyrkov <maxim.kuvyrkov@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?
>
> 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
>
>
>
--
Maxim Kuvyrkov
www.linaro.org