This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Kernel livepatching support in GCC
- From: Andi Kleen <ak at linux dot intel dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, Richard Guenther <richard dot guenther at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, Li Bin <huawei dot libin at huawei dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>
- Date: Tue, 9 Jun 2015 08:52:57 -0700
- Subject: Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org> <CEDC3659-14B8-42A4-9ED8-485EC62B615C at gmail dot com> <535E656D-9CA2-4506-8918-CD73C0F63F84 at linaro dot org> <55673651 dot 8070802 at linux dot vnet dot ibm dot com> <20150604071531 dot GA17023 at domone> <5576F3D7 dot 4060001 at linux dot vnet dot ibm dot com>
> > 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
> > depend on address, fill with nops as trivial first implementation.
> > Would that be possible?
> So instead of placing NOPs to be overwritten you intend to simply overwrite the existing code after
> making a backup of it?
This is how Linux k/uprobes work. But it only works for a subset of instructions and is
fairly complicated because you need a complete decoder that is able to adjust any program counter
relative data offsets. Having a patch area is far easier and more reliable.
email@example.com -- Speaking for myself only