Re: arm64:, Re: [RFC] Kernel livepatching support in GCC

2015-10-23 Thread Szabolcs Nagy
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 sho

Re: arm64:, Re: [RFC] Kernel livepatching support in GCC

2015-10-23 Thread AKASHI Takahiro
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, we should implement a t

Re: [RFC] Kernel livepatching support in GCC

2015-10-22 Thread libin
在 2015/10/22 18:16, Szabolcs Nagy 写道: > On 22/10/15 10:23, libin wrote: >> From: Jiangjiji >> Date: Sat, 10 Oct 2015 15:29:57 +0800 >> Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option. >> * gcc/config/aarch64/aarch64.c: Add some new functions and Macros. >> * gcc/config/aa

Re: arm64:, Re: [RFC] Kernel livepatching support in GCC

2015-10-22 Thread Szabolcs Nagy
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, we should implement a target-independent option -fprolog-pad=N, which

Re: [RFC] Kernel livepatching support in GCC

2015-10-22 Thread Szabolcs Nagy
On 22/10/15 10:23, libin wrote: From: Jiangjiji Date: Sat, 10 Oct 2015 15:29:57 +0800 Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option. * gcc/config/aarch64/aarch64.c: Add some new functions and Macros. * gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFI

arm64:, Re: [RFC] Kernel livepatching support in GCC

2015-10-22 Thread AKASHI Takahiro
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

Re: [RFC] Kernel livepatching support in GCC

2015-10-22 Thread libin
From: Jiangjiji Date: Sat, 10 Oct 2015 15:29:57 +0800 Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option. * gcc/config/aarch64/aarch64.c: Add some new functions and Macros. * gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFILER. Signed-off-by: Jiangjiji Sign

Re: [RFC] Kernel livepatching support in GCC

2015-10-22 Thread libin
在 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-

Re: [RFC] Kernel livepatching support in GCC

2015-10-13 Thread Maxim Kuvyrkov
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 wrote: > Hi, > > Akashi-san and I have been discussing require

Re: [RFC] Kernel livepatching support in GCC

2015-06-09 Thread Andi Kleen
> > As I am bit concerned with performance why require nops there? Add a > > byte count number >= requested thats boundary of next instruction. When > > lifepatching for return you need to copy this followed by jump back to next > > instruction. Then gcc could fill that with instructions that don't

Re: [RFC] Kernel livepatching support in GCC

2015-06-09 Thread Andreas Krebbel
On 06/04/2015 09:15 AM, Ondřej Bílka wrote: > On Thu, May 28, 2015 at 05:37:53PM +0200, Andreas Krebbel wrote: >> On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote: On May 28, 2015, at 11:59 AM, Richard Biener wrote: >> ... Maybe follow s390 -mhotpatch instead? >>> >>> Regarding impleme

Re: [RFC] Kernel livepatching support in GCC

2015-06-04 Thread Andrew Pinski
On Thu, Jun 4, 2015 at 11:17 PM, Andi Kleen wrote: >> Rather than just a sequence of NOP's, should the first NOP be a >> unconditional branch to the beginning of the real function? I don't >> know if this applies to AArch64 cpus, but I believe some cpus can handle >> such branches already in the

Re: [RFC] Kernel livepatching support in GCC

2015-06-04 Thread Andi Kleen
> Rather than just a sequence of NOP's, should the first NOP be a > unconditional branch to the beginning of the real function? I don't > know if this applies to AArch64 cpus, but I believe some cpus can handle > such branches already in the decode unit, thus avoiding any extra cycles > for skippi

Re: [RFC] Kernel livepatching support in GCC

2015-06-04 Thread David Brown
On 28/05/15 10:39, Maxim Kuvyrkov 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-mcou

Re: [RFC] Kernel livepatching support in GCC

2015-06-04 Thread Ondřej Bílka
On Thu, May 28, 2015 at 05:37:53PM +0200, Andreas Krebbel wrote: > On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote: > >> On May 28, 2015, at 11:59 AM, Richard Biener > >> wrote: > ... > >> Maybe follow s390 -mhotpatch instead? > > > > Regarding implementation of the option, it will follow what s390

Re: [RFC] Kernel livepatching support in GCC

2015-05-30 Thread Li Bin
On 2015/5/28 16:39, Maxim Kuvyrkov 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-

Re: [RFC] Kernel livepatching support in GCC

2015-05-28 Thread Jim Wilson
On 05/28/2015 01:39 AM, Maxim Kuvyrkov 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 -mrec

Re: [RFC] Kernel livepatching support in GCC

2015-05-28 Thread Andi Kleen
> 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 sim

Re: [RFC] Kernel livepatching support in GCC

2015-05-28 Thread Andreas Krebbel
On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote: >> On May 28, 2015, at 11:59 AM, Richard Biener >> wrote: ... >> Maybe follow s390 -mhotpatch instead? > > Regarding implementation of the option, it will follow what s390 is doing > with function attributes to mark which functions to apply nop-trea

Re: [RFC] Kernel livepatching support in GCC

2015-05-28 Thread Maxim Kuvyrkov
> On May 28, 2015, at 11:59 AM, Richard Biener > wrote: > > On May 28, 2015 10:39:27 AM GMT+02:00, Maxim Kuvyrkov > 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 livep

Re: [RFC] Kernel livepatching support in GCC

2015-05-28 Thread Richard Biener
On May 28, 2015 10:39:27 AM GMT+02:00, Maxim Kuvyrkov 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 -mfent

[RFC] Kernel livepatching support in GCC

2015-05-28 Thread 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 a