From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20603 invoked by alias); 30 Nov 2015 19:39:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20593 invoked by uid 89); 30 Nov 2015 19:39:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 30 Nov 2015 19:39:11 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id E7E8532B635; Mon, 30 Nov 2015 19:39:09 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAUJd89N020042; Mon, 30 Nov 2015 14:39:08 -0500 Message-ID: <565CA5DC.9030009@redhat.com> Date: Mon, 30 Nov 2015 19:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Marchi , Yao Qi , gdb-patches@sourceware.org Subject: Re: Move threads out of jumppad without single step References: <86zixzvhj1.fsf@gmail.com> <565C6043.4040106@redhat.com> <565C9DA8.4010605@ericsson.com> In-Reply-To: <565C9DA8.4010605@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00612.txt.bz2 On 11/30/2015 07:04 PM, Simon Marchi wrote: > On 15-11-30 09:42 AM, Pedro Alves wrote: >> So I assume it's much simpler to just run to [1] as well, and then issue >> a normal software single-step when you get there. >> >> Also, not sure, but it's possible the stabilize threads machinery may >> need work to handle the "wrong threads" hitting that "out of jump pad" >> single-step breakpoint for another thread, and not have them start >> a new start over, but instead have them be locked immediately. > > To be clear, do you mean, when single stepping the last jump pad instruction, > the jump that goes back to the regular code? When putting a breakpoint on the > next pc of that instruction, it means putting a breakpoint in the regular code. Right. > > However, when doing a single step in gdbserver, aren't all other threads stopped? > That's really a function of whether we're stepping over a breakpoint; in that case we must stop all threads, but that's true when you step past a breakpoint with either software single-step or hardware single-step. IOW, it's an orthogonal, though tangent issue. E.g., when software single stepping for a tracepoint's while-stepping action, I don't see why you'd stop all threads. In this case, if the thread reached the breakpoint set at the last instruction of the jump pad, we don't need that breakpoint anymore. So for the last single-step we can compute the next PC, install a breakpoint there, and continue, no need to start a step-over process (pause all threads, remove bp, step, reinsert bp, unpause all). On the other hand, always leaving that breakpoint inserted while the stabilization is in progress and then making that final single-step be a step-over operation could make things simpler. Or not, not sure. We currently track the breakpoint's lifetime by putting it in the lwp structure (lwp->exit_jump_pad_bkpt), because it's per-lwp. If we keep it inserted, then we need to track its lifetime differently. Thanks, Pedro Alves