From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11209 invoked by alias); 19 May 2015 18:08:24 -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 11191 invoked by uid 89); 19 May 2015 18:08:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Tue, 19 May 2015 18:08:23 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id E1979B595D; Tue, 19 May 2015 18:08:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4JI8K1h008871; Tue, 19 May 2015 14:08:21 -0400 Message-ID: <555B7C14.1020504@redhat.com> Date: Tue, 19 May 2015 18:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode References: <1429267521-21047-1-git-send-email-palves@redhat.com> <1429267521-21047-11-git-send-email-palves@redhat.com> <86a8y1zqkd.fsf@gmail.com> <5538017B.9040907@redhat.com> <86h9s6x9eo.fsf@gmail.com> In-Reply-To: <86h9s6x9eo.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00492.txt.bz2 Hi Yao, I had not realized I missed answering this. On 04/24/2015 08:39 AM, Yao Qi wrote: > Pedro Alves writes: > >>> This path is about the case that a signal is got while in in-line >>> stepping, isn't? If so, non_stop should be an invariant false. We >>> don't need to check it. >> >> Hmm, not sure what you mean: >> > > Let me ask it in another way, when we get here, it means a signal > arrived, the code some lines above is: > > if (debug_infrun) > fprintf_unfiltered (gdb_stdlog, > "infrun: signal arrived while stepping over " > "breakpoint\n"); > > GDB just did the breakpoint step over, via in-line stepping or > out-of-line stepping, right? as your patch below shows. > >> - We need to do this with displaced stepping too, because we can't >> deliver signals while doing a displaced step. See comments at the >> top of displaced_step_prepare and in do_target_resume. > > The first sentence is contradictory, or you mean we *can* do either > out-of-line stepping or in-line stepping, but we can't deliver a signal > while doing a displaced stepping... By "need to do this" I meant that we need to cancel the step over in progress, and insert the step-resume at the signal handlers return. > >> >> - We can certainly get a signal while doing an in-line step-over. >> The simplest would be, trying to step-over a breakpoint here: >> >> *(volatile int *)0 = 1; >> >> which usually results SIGSEGV. > > ... while we can deliver a signal in in-line stepping. Is it correct? > Not really. We can't deliver a signal while a displaced step is in progress, because we wouldn't be able to tell whether the thread stepped to the handler or to main line code, so we wouldn't know whether to apply the displaced step fixup. Also, if the thread stops for some reason while in the handler, we'd end up with the scratch pad still in the frame chain, so later when the thread is re-resumed, it'd return to the scratch pad, but the scratch pad would have already have been overwritten. And we can't deliver a signal while stepping over a breakpoint in-line either, because that requires removing the breakpoint, and the signal handler can recurse and call the same code that had the breakpoint we were stepping over -- which would mean we'd miss trapping on that breakpoint. (this is tested by signest.exp). So the only difference between stepping over a breakpoint in-line or out-of-line here, is that with the former, threads had been previously paused, so we re-resume them while the signal handler runs (to avoid debugger-induced inferior deadlock). Let me know if that answered your question. Thanks, Pedro Alves