----- On Nov 22, 2017, at 2:37 PM, Will Deacon will.deacon@xxxxxxx wrote: > 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. Considering the arm 64 use-case of reading PMU counters from user-space using rseq to prevent migration, I understand that you're lucky enough to already have a system call at your disposal that can perform the slow-path in case of single-stepping. So yes, your particular case is already covered, but unfortunately that's not the same situation for other use-cases that have been expressed. Thanks, Mathieu > > Will -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- 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
