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 >
