From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24903 invoked by alias); 12 Sep 2014 18:08:47 -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 24889 invoked by uid 89); 12 Sep 2014 18:08:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f202.google.com Received: from mail-ig0-f202.google.com (HELO mail-ig0-f202.google.com) (209.85.213.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 12 Sep 2014 18:08:45 +0000 Received: by mail-ig0-f202.google.com with SMTP id h18so125560igc.3 for ; Fri, 12 Sep 2014 11:08:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=Ahw8IKSG63AI9gMsU+6XnQyLUI6DlufExTWIDCpuhPA=; b=hgUuzse/QP5htvWoML0g58ko2gVGlM4JcUHJ7PPrVc36VrR/W8cUJ4IJeOleCecvSN +wEJGMOujgI3lKv35944dOlllt1pmcWaWyTIKqDKMSAJ70nhH08FvEEeUfk/xqn2q+0v 7G9nK8eZWLUXoP+1Be1egRrATqHEBAMIj71PlppKY7YnrNODQ2HZUXMyxEOWgqk5qHy5 6jqCTN/9ZvcuhkWy+O4BVDRIAnz5Biahbi8lT+HHTFFVGJygszRrxG2KkC/ptPDy56mY OGt+fLybwWSACbATKUHDbdn31nyREhxAT1YPrZ6feJt6meA3SO4D0K3CWFs6X6H7clse uFvQ== X-Gm-Message-State: ALoCoQnq8BcmCwYV4mwzvMXQ/2L23Ov3UfzxoVcAcX7uKzsPBFy5NkZGOfjr/njpRUQaZPOIM+g9D6S1pBR5psWRNA//M1TAv+4t16cYQvTZGrhoTFQezwt1sHZ2QfqrAIj5eqv5y5O3HkubmQktJT3AulUTfpceAgbmlC8v+IJcuKY4ZC0dDk8= X-Received: by 10.182.166.73 with SMTP id ze9mr5395215obb.4.1410545323212; Fri, 12 Sep 2014 11:08:43 -0700 (PDT) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id n24si214548yha.6.2014.09.12.11.08.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 11:08:43 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id Uip7Noxu.1; Fri, 12 Sep 2014 11:08:43 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21523.13993.986533.615240@ruffy2.mtv.corp.google.com> Date: Fri, 12 Sep 2014 18:08:00 -0000 To: Pedro Alves Cc: Gary Benson , gdb-patches@sourceware.org Subject: Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid In-Reply-To: <5413305B.6020402@redhat.com> References: <1409320299-6812-1-git-send-email-gbenson@redhat.com> <1409320299-6812-4-git-send-email-gbenson@redhat.com> <21520.36381.756875.963606@ruffy2.mtv.corp.google.com> <20140911102659.GA17472@blade.nx> <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> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00447.txt.bz2 Pedro Alves writes: > On 09/12/2014 06:38 PM, Doug Evans wrote: > > Pedro Alves writes: > > > On 09/12/2014 05:53 PM, Doug Evans wrote: > > > > > > > That may be sufficient for me to make this patch checkin-able, > > > > but before then I'd like to understand how and where > > > > this function will be used from gdb. > > > > > > Can you clarify? I don't have any plan to use this > > > elsewhere myself. All we're doing is factoring out > > > the current use behind a common function so that both gdb > > > and gdbserver can implement it their own way. > > > > I don't see the function being used in gdb by this patch set. > > So, absent further info, the change to gdb/target.c is just adding > > dead code. I'm assuming that's not the case (*1), but until I > > understand how it's going to be used in gdb it's not clear to > > me whether code that uses it will be confusing to read. > > It's used in common/agent.c, which is used by gdb as well. > > linux-nat.c: agent_run_command (pid, s, strlen (s) + 1); > linux-nat.c: agent_run_command (pid, s, strlen (s) + 1); > > It's because it's used in gdb that the current code, before > Gary's patch has the #ifdef GDBSERVER #else /* gdb code */ bits. > He's just moving that code around. Ah. I'm liking target_continue_with_no_signal even more. [assuming one wants to leave the signature as is] btw, I noticed this 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); And I remembered you saying: > 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] The function comment for target_stop says nothing one way or the other about whether it's asynchronous which doesn't help.