On Tue, Apr 19, 2016 at 09:39:39AM +0300, Alexander Monakov wrote: > On Tue, 19 Apr 2016, AKASHI Takahiro wrote: > > > > But if Szabolcs' two-instruction > > > > sequence in the adjacent subthread is sufficient, this is moot. > > > > > > . It can also be solved by having just one NOP after the function label, > > > and a number of them before, then no thread can be in the nop pad. That > > > seems to indicate that GCC should not try to be too clever and simply > > > leave the specified number of nops before and after the function label, > > > leaving safety measures to the patching infrastructure. > > > > I don't get this idea very well. > > How can the instructions *before* a function label be executed > > after branching into this function? > > The single nop after the function label is changed to a short backwards branch > to the instructions just before the function label. > > As a result, the last instruction in the pad would have to become a short > forward branch jumping over the backwards branch described above, to the first > real instruction of the function.
So you mean something like: 1: str x30, [sp, #-8]! bl _tracefunc ldr x30, [sp], #8 b 2f .global <function label> b 1b 2: <function prologue/body> ... (We will not have to use x9 or else to preserve x30 here.) Interesting. Livepatch code in the kernel has an assumption that the address of "bl _tracefunc" be equal to <function label>, but a recent patch for power pc to support livepatch tries to ease this restriction [1], and so hopefully it won't be an issue. (I will have to dig into the kernel code to be sure that there is no other issues though.) Thanks, -Takahiro AKASHI [1] http://lkml.iu.edu//hypermail/linux/kernel/1604.1/04111.html and http://lkml.iu.edu//hypermail/linux/kernel/1604.1/04112.html > Alexander
