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