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. 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. Ciao, Michael.
