From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126637 invoked by alias); 26 Nov 2015 16:51:40 -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 126624 invoked by uid 89); 26 Nov 2015 16:51:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f51.google.com Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 Nov 2015 16:51:38 +0000 Received: by pacdm15 with SMTP id dm15so90637598pac.3 for ; Thu, 26 Nov 2015 08:51:36 -0800 (PST) X-Received: by 10.98.70.138 with SMTP id o10mr41431064pfi.17.1448556696394; Thu, 26 Nov 2015 08:51:36 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id rz10sm29182626pac.29.2015.11.26.08.51.33 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 26 Nov 2015 08:51:35 -0800 (PST) From: Yao Qi To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 11/18] gdbserver: fix killed-outside.exp References: <1444836486-25679-1-git-send-email-palves@redhat.com> <1444836486-25679-12-git-send-email-palves@redhat.com> <86ziz4zlof.fsf@gmail.com> <5655CE81.3090603@redhat.com> Date: Thu, 26 Nov 2015 16:51:00 -0000 In-Reply-To: <5655CE81.3090603@redhat.com> (Pedro Alves's message of "Wed, 25 Nov 2015 15:06:41 +0000") Message-ID: <86fuzswvov.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00573.txt.bz2 Pedro Alves writes: >>> - /* If we got a `vCont;t', but we haven't reported a stop yet, do >>> - report any status pending the LWP may have. */ >>> - if (thread->last_resume_kind =3D=3D resume_stop >>> - && thread->last_status.kind !=3D TARGET_WAITKIND_IGNORE) >>> - return 0; >>> - >>=20 >> Shouldn't we return 1 instead of 0 here? This is consistent with the >> comments above. > > I may have misunderstood what you mean, but if we remove this code, > that's what we get -- the "return 1;" at the end is reached. > What I meant is to change "return 0" to "return 1", like, /* If we got a `vCont;t', but we haven't reported a stop yet, do report any status pending the LWP may have. */ if (thread->last_resume_kind =3D=3D resume_stop && thread->last_status.kind !=3D TARGET_WAITKIND_IGNORE) - return 0; + return 1; that is the same as removing them. >>=20 >>> if (thread->last_resume_kind !=3D resume_stop >>> && (lp->stop_reason =3D=3D TARGET_STOPPED_BY_SW_BREAKPOINT >>> || lp->stop_reason =3D=3D TARGET_STOPPED_BY_HW_BREAKPOINT)) >>> @@ -1597,6 +1591,24 @@ thread_still_has_status_pending_p (struct thread= _info *thread) >>> return 1; >>> } >>>=20=20 >>> +/* Returns true if LWP is resumed from the client's perspective. */ >>> + >>> +static int >>> +lwp_resumed (struct lwp_info *lwp) >>> +{ >>> + struct thread_info *thread =3D get_lwp_thread (lwp); >>> + >>> + if (thread->last_resume_kind !=3D resume_stop) >>> + return 1; >>> + >>> + /* Did we get a `vCont;t', but we haven't reported a stop yet? */ >>> + if (thread->last_resume_kind =3D=3D resume_stop >>> + && thread->last_status.kind =3D=3D TARGET_WAITKIND_IGNORE) >>> + return 1; >>> + >>=20 >> I feel "reported" isn't precise. Is "got" better? The code means >> GDBserver has already got vCont;t and sent SIGSTOP, but hasn't *got* >> stop event out of event loop. After GDBserver got this event, it then >> reports the event back to GDB if needed. > > Hmm, reported to gdb is really what I mean. How about this: > > /* Did gdb send us a `vCont;t', but we haven't reported the > corresponding stop to gdb yet? If so, the thread is still > resumed/running from gdb's perspective. */ > if (thread->last_resume_kind =3D=3D resume_stop > && thread->last_status.kind =3D=3D TARGET_WAITKIND_IGNORE) > return 1; Oh, sounds it is about thread's state from GDB's perspective. Patch is good to me. By the way, after GDBserver reported the stop GDB, does the thread changed to (thread->last_resume_kind =3D=3D resume_stop && thread->last_status.kind !=3D TARGET_WAITKIND_IGNORE) it is used in proceed_one_lwp. --=20 Yao (=E9=BD=90=E5=B0=A7)