This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
- From: Torsten Duwe <duwe at lst dot de>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Apr 2016 18:03:13 +0200
- Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64
- Authentication-results: sourceware.org; auth=none
On Mon, Apr 18, 2016 at 02:12:09PM +0200, Michael Matz wrote:
>
> . It can also be solved by having just one NOP after the function label,
> and a number of them before, then no thread can be in the nop pad. That
> seems to indicate that GCC should not try to be too clever and simply
> leave the specified number of nops before and after the function label,
> leaving safety measures to the patching infrastructure.
Yes, please. Consistency is required to maintain a sane stream of instructions
for all CPUs involved; this gets particularily nasty on x86 byte code that
can in theory cross a cache line boundary with every byte. ARM does not have
this problem. Even if it had, it would be a kernel problem, not the compiler's.
All that kernel live patching needs is some space to place the patch calls.
I currently see the need for 2 NOPs at the beginning of each function; making
that configurable would be a plus; leaving additional configurable space
before the entry point would be even more flexible.
Fentry, like ppc64 profile-kernel, does more than necessary by generating
a call already. On ppc64 currently, that branch target isn't even actively
used, and the first thing the kernel does is patch these calls with NOPs.
So why not start with the NOPs right away? An architecture-independent,
variable number might stimulate use cases on other OSes and architectures
as well.
Torsten