Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

On 18/04/16 14:26, Alexander Monakov wrote:
> On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
>> looking at [2] i don't see why
>>
>> func:
>>   mov x9, x30
>>   bl _tracefunc
>>   <function body>
>>
>> is not good for the kernel.
>>
>> mov x9, x30 is a nop at function entry, so in
>> theory 4 byte atomic write should be enough
>> to enable/disable tracing.
> 
> Overwriting x9 can be problematic because GCC has gained the ability to track
> register usage interprocedurally: if foo() calls bar(), and GCC has already
> emitted code for bar() and knows that it cannot change x9, it can use that
> knowledge to avoid saving/restoring x9 in foo() around calls to bar(). See
> option '-fipa-ra'.
> 
> If there's no register that can be safely used in place of x9 here, then
> the backend should emit the entry/pad appropriately (e.g. with an unspec that
> clobbers the possibly-overwritten register).
> 

(1) nop padded function can be assumed to clobber all temp regs
(2) or _tracefunc must save/restore all temp regs, not just arg regs.

on x86_64, glibc and linux _mcount and __fentry__ don't
save %r11 (temp reg), only the arg regs, so i think nop
padding should behave the same way (1).

> Or, with Michael Matz' suggestion, there can be one nop at function start and
> a big enough pad just before the function, and that pad can just push/pop x30
> on its own.
> 
> Alexander
>