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

[Ramana Radhakrishnan <ramana.gcc@googlemail.com>]

On Mon, Apr 18, 2016 at 2:26 PM, Alexander Monakov <amonakov@ispras.ru> 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).

Can you not use one of x16 / x17 the intra-procedure-call scratch
registers as per the PCS ?

regards
Ramana

>
> 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