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