This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Kernel livepatching support in GCC
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>,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>
- Date: Thu, 28 May 2015 10:59:10 +0200
- Subject: Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org>
On May 28, 2015 10:39:27 AM GMT+02:00, Maxim Kuvyrkov <firstname.lastname@example.org> wrote:
>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 .
>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.
Maybe follow s390 -mhotpatch instead?
>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 since most of the livepatching changes are in the kernel.
> 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.