----- On Apr 7, 2016, at 6:05 PM, Andy Lutomirski luto@xxxxxxxxxxxxxx wrote: > On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: >> On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote: [...] >> >>> it's inherently debuggable, >> >> It is more debuggable, agreed. >> >>> and it allows multiple independent >>> rseq-protected things to coexist without forcing each other to abort. [...] My understanding is that the main goal of this rather more complex proposal is to make interaction with debuggers more straightforward in cases of single-stepping through the rseq critical section. I recently came up with a scheme that should allow us to handle such situations in a fashion similar to debuggers handling ll/sc restartable sequences of instructions on e.g. powerpc. The good news is that my scheme does not require anything at the kernel level. The idea is simple: the userspace rseq critical sections now become marked by 3 inline functions (rather than 2 in Paul's proposal): rseq_start(void *rseq_key) rseq_finish(void *rseq_key) rseq_abort(void *rseq_key) We associate each critical section with a unique "key" (dummy 1 byte object in the process address space), so we can group them. The new "rseq_abort" would mark exit points that would exit the critical section without executing the final commit instruction. Within each of rseq_start, rseq_finish and rseq_abort, we declare a non-loadable section that gets populated with the following tuples: (RSEQ_TYPE, insn address, rseq_key) Where RSEQ_TYPE is either RSEQ_START, RSEQ_FINISH, or RSEQ_ABORT. That special section would be found in the executable by the debugger, which can then skip over entire restartable critical sections when it encounters them by placing breakpoints at all exit points (finish and cancel) associated to the same rseq_key as the entry point (start). This way we don't need to complexify the runtime code, neither at kernel nor user-space level, and we get debuggability using a trick similar to what ll/sc architectures already need to do. Of course, this requires extending gdb, which should not be a show-stopper. Thoughts ? Thanks, Mathieu -- 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
