On Wed, Nov 22, 2017 at 08:32:19PM +0100, Peter Zijlstra wrote: > On Tue, Nov 21, 2017 at 10:05:08PM +0000, Mathieu Desnoyers wrote: > > Other than that, I have not received any concrete alternative proposal to > > properly handle single-stepping. > > That's not entirely true; amluto did have an alternative in Prague: do > full machine level instruction emulation till the end of the rseq when > it gets 'preempted too often'. > > Yes, implementing that will be an absolute royal pain. But it does > remove the whole duplicate/dual program asm/bytecode thing and avoids > the syscall entirely. > > And we don't need to do a full x86_64/arch-of-choice emulator for this > either; just as cpu_opv is fairly limited too. We can do a subset that > allows dealing with the known sequences and go from there -- it can > always fall back to not emulating and reverting to the pure rseq with > debug/fwd progress 'issues'. > > So what exactly is the problem of leaving out the whole cpu_opv thing > for now? Pure rseq is usable -- albeit a bit cumbersome without > additional debugger support. Drive-by "ack" to that. I'd really like a working rseq implementation in mainline, but I don't much care for another interpreter. Will -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
