From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16624 invoked by alias); 16 Sep 2014 09:49:20 -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 16567 invoked by uid 89); 16 Sep 2014 09:49:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Tue, 16 Sep 2014 09:49:18 +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 (8.14.4/8.14.4) with ESMTP id s8G9nFm9032214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 16 Sep 2014 05:49:16 -0400 Received: from blade.nx (ovpn-116-123.ams2.redhat.com [10.36.116.123]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8G9nEnu001633; Tue, 16 Sep 2014 05:49:15 -0400 Received: by blade.nx (Postfix, from userid 1000) id 29BCA2640D5; Tue, 16 Sep 2014 10:49:14 +0100 (BST) Date: Tue, 16 Sep 2014 09:49:00 -0000 From: Gary Benson To: Doug Evans Cc: Pedro Alves , gdb-patches Subject: Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid Message-ID: <20140916094914.GB32511@blade.nx> References: <5412DEB5.6020706@redhat.com> <21523.9502.168492.803068@ruffy2.mtv.corp.google.com> <54132B55.9000108@redhat.com> <21523.12189.134570.770432@ruffy2.mtv.corp.google.com> <5413305B.6020402@redhat.com> <21523.13993.986533.615240@ruffy2.mtv.corp.google.com> <54133939.70801@redhat.com> <20140915100736.GA13503@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00519.txt.bz2 Doug Evans wrote: > On Mon, Sep 15, 2014 at 3:07 AM, Gary Benson wrote: > > Doug Evans wrote: > > > On Fri, Sep 12, 2014 at 11:19 AM, Pedro Alves wrote: > > > > On 09/12/2014 07:08 PM, Doug Evans wrote: > > > > > Pedro Alves wrote: > > > > > > I just now noticed the elephant in the room -- target_stop > > > > > > is asynchronous, doesn't wait for a stop, while and > > > > > > target_stop_ptid is synchronous. [...] > > > > > > > > > > If the above code is right, I think a clarifying comment is > > > > > required somewhere. It's odd that one can call > > > > > agent_run_command when the inferior may or may not be stopped > > > > > yet. [Or is there a bug here? - if I'm reading the gdbserver > > > > > version correctly it first waits for the inferior to stop] > > > > > > > > It's a bug. > > > > > > > > (Note that the GDB side interfaces with an out-of-tree > > > > agent, not GDBserver's agent. I don't know the status of > > > > that agent.) > > > > > > Data point that target_stop should be named target_stop_async? > > > > Ok, can I get a summary of this thread, I'm struggling to follow it. > > > > a) What should the functions be called: > > - target_stop_async / target_stop_wait > > - target_continue_async / target_continue_no_signal > > - something else? > > > > b) Is there a bug here I need to address? > > At this point I think we're still in discussion mode, there are no > conclusions/agreements yet, except for the agreement to use > target_continue_with_no_signal instead of target_continue_ptid. > > To advance the discussion, > the async case is the subtle case IMO. Evidently (and I'm just going > by what I see, there may be more data here) someone (*1) looked at the > name "target_stop" and thought it was async (which is probably what > I'd do). The function comment doesn't specify. One could argue it's > sufficient to just fix the function comment, but if we're going to > have a mix of similar functions, some of which are async and some > sync, then IMO we should also make the difference stand out in the > code where it's read. I'd be happy with a convention where all async > functions ended with _async or _no_wait (the latter reads better to > me), but I'm guessing I'd be happy with a different convention as > well. > > FAOD, > there is a bug, but it's not one you specifically need to address. > I pointed it out because it's a data point that contributes to the discussion. > > (*1): I've looked at git log and blame. I'm speaking generically here > because I think this is unlikely to be a one-off kind of issue. Plus I > can well imagine me making a similar mistake too. Plus the bug got > through code review. Ok, so what I think you're saying is: a) The target_stop method in GDB should be renamed target_stop_async b) The common code target_stop_ptid should be renamed... target_stop ? c) The bug is that in this code in linux-nat.c: /* Pause all */ target_stop (ptid); memcpy (s, "qTfSTM", sizeof ("qTfSTM")); s[sizeof ("qTfSTM")] = 0; agent_run_command (pid, s, strlen (s) + 1); the "target_stop" should actually be a call to whatever target_stop_ptid is renamed to. One final thing--and I may now be going over something that has been discussed before--could target_continue_ptid be better renamed as target_resume_no_signal? It seems to sit better alongside GDB's target_resume. Thanks, Gary -- http://gbenson.net/