Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753848AbcDJOHr (ORCPT ); Sun, 10 Apr 2016 10:07:47 -0400 Received: from mail.efficios.com ([78.47.125.74]:39931 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753152AbcDJOHp (ORCPT ); Sun, 10 Apr 2016 10:07:45 -0400 Date: Sun, 10 Apr 2016 14:07:36 +0000 (UTC) From: Mathieu Desnoyers To: Linus Torvalds Cc: Andy Lutomirski , Peter Zijlstra , "Paul E. McKenney" , Ingo Molnar , Paul Turner , Andi Kleen , Chris Lameter , Dave Watson , Josh Triplett , linux-api , Linux Kernel Mailing List , Andrew Hunter Message-ID: <1611812099.51589.1460297256829.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20151027235635.16059.11630.stgit@pjt-glaptop.roam.corp.google.com> <20160407201156.GC3448@twins.programming.kicks-ass.net> <1802683892.49910.1460077902922.JavaMail.zimbra@efficios.com> <427613474.49955.1460081105607.JavaMail.zimbra@efficios.com> <65466698.51122.1460137589499.JavaMail.zimbra@efficios.com> Subject: Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF45 (Linux)/8.6.0_GA_1178) Thread-Topic: restartable sequences v2: fast user-space percpu critical sections Thread-Index: L6QqYUJLrdvcYVy0bQfoSBxuXFUwGg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2228 Lines: 53 ----- On Apr 8, 2016, at 5:25 PM, Linus Torvalds torvalds@linux-foundation.org wrote: > On Fri, Apr 8, 2016 at 10:46 AM, Mathieu Desnoyers > wrote: >> >> By the way, the debugger can always decide to single-step through the >> first iteration of the rseq, and then after it loops, decide to skip >> single-stepping until the exit points are reached. > > A _human_ debugger may decide to do that yes. > > But the the debugger _program_ may not be that smart. For example, > let's say that you - as a human - set a few watchpoints. The debugger > will use hardware breakpoints for the first few, but in more complex > cases the debugger will actually say "oops, no more hw breakpoints, > I'll just start single-stepping instead". > > The human operator may not even be aware that the debugger has gone > into that slower mode. Normally it's just slower. But you'd want it to > be _only_ slower, not "oops, the program no longer makes any forward > progress at all, because a library that the user didn't even know or > care about - and never sees, because the single-stepping is all > internal = happened to use a code sequence that doesn't work under > single-stepping". Which is why I'm proposing to extend gdb to support this automatically, without requiring interaction or knowledge from the user. The idea is to let gdb detect entry points into those restartable critical sections as it single-steps through the program. It would know about all rseq c.s. exit points too, so it can track whether it has single-stepped over an entire rseq c.s. and thus caused a restart. At that point, it can put the breakpoint at each exit point associated with the entry point, thus skipping single-step of the second iteration of the critical section. I think this could be achieved by populating a section that contains information about entry and exit points of those critical sections in the rseq_{start,finish,abort} functions. Those sections would end up in the app/lib ELF binary, may not have to be necessarily loaded into program's memory. Does it make sense to try it out, or am I missing something obvious ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com