On Mon, Apr 18, 2016 at 02:12:09PM +0200, Michael Matz wrote: > Hi, > > On Sun, 17 Apr 2016, Alexander Monakov wrote: > > > I've noticed an issue in my (and probably Michael's) solution: if > > there's a thread that made it past the first nop, but is still executing > > the nop pad, it's unsafe to replace the nops.
Yeah, this issue also trapped me before :) > To solve that, it > > suffices to have a forward branch in place of the first nop to begin > > with (i.e. have the compiler emit it). > > True. I wonder if the generic solution in GCC should do that always or if > the patch infrastructure should do that to enable more freedom like doing > this: > > > 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? Thanks, -Takahiro AKASHI > > Ciao, > Michael. -- Thanks, -Takahiro AKASHI
