From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2213 invoked by alias); 12 Sep 2014 16:53:55 -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 2094 invoked by uid 89); 12 Sep 2014 16:53:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 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-pa0-f73.google.com Received: from mail-pa0-f73.google.com (HELO mail-pa0-f73.google.com) (209.85.220.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 12 Sep 2014 16:53:53 +0000 Received: by mail-pa0-f73.google.com with SMTP id kx10so206742pab.2 for ; Fri, 12 Sep 2014 09:53:51 -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=A/3lSZODhxqZ47cwzJgG/Fq6sbfvtfypTD5x93gTDZ8=; b=eq33SI+i71fFKa05O5e35N5wCkE7uy02v1fXEMuWKCc8R24PcCXCRgFk0pgig/4tk3 X6Dt3jzZ+XRunZhm/J5To/dOeygVURECNDXAfI1OEfudZu0lTM/2KEpCdFWnoJGC+0Md NOMrd/BEfdL5r5RooGktQwdDsIBMOthI9CbqF2pmyRbg/FTos7ISCD+ATjfkOflHpKSs 8jw3aiHVLMin01VOZrgw9OlXELi6VC2C8f/+H9biegY0TriN15vUszyLwn1TTEsHZQ7F K+dReJsEHpIluUzcD7VqtorQi8CQjh6y7wutwGk33EYn1g5k3KHu8FbgmYimHI4zgZlc 6gcQ== X-Gm-Message-State: ALoCoQlYn7L0/Z4GaxKlEhELmWDNIBbJn4VZZJxVw48OK7jZUTc9ctiY2gn2aO98nXeCq/i9KEfplD2D8hZ3t/sEgUhck4ot2OW/rKytJQ66sPu9zbJ202AfVDOb/w33ohXAdb5vhKLhKHNiREkwCSqrvQPAwZhdtKlCTUKJMM3PJhFtE8DeLfM= X-Received: by 10.66.241.104 with SMTP id wh8mr5030779pac.33.1410540831383; Fri, 12 Sep 2014 09:53:51 -0700 (PDT) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id n63si204323yho.5.2014.09.12.09.53.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 09:53:51 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id GNzrIZVX.1; Fri, 12 Sep 2014 09:53:51 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21523.9502.168492.803068@ruffy2.mtv.corp.google.com> Date: Fri, 12 Sep 2014 16:53: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: <5412DEB5.6020706@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> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00438.txt.bz2 Pedro Alves writes: > On 09/11/2014 11:26 AM, Gary Benson wrote: > > Doug Evans wrote: > >> Gary Benson writes: > >>> This commit introduces two new functions to stop and restart > >>> target processes that shared code can use and that clients must > >>> implement. It also changes some shared code to use these > >>> functions. > >> [...] > >>> +/* See target/target.h. */ > >>> + > >>> +void > >>> +target_continue_ptid (ptid_t ptid) > >>> +{ > >>> + target_resume (ptid, 0, GDB_SIGNAL_0); > >>> +} > >> > >> How come GDB_SIGNAL_0 is used here? > >> Maybe it's correct, but it's not immediately clear. > >> > >> The reason I ask is because there are two ways to "continue" > >> the inferior: > >> 1) resume it where it left off, and if it stopped because > >> of a signal then forward on that signal (assuming the > >> signal is not "nopass") (GDB_SIGNAL_DEFAULT). > >> 2) Either inject a new signal (GDB_SIGNAL_FOO) or cancel out > >> a previously queued signal (GDB_SIGNAL_0). > >> > >> GDB_SIGNAL_0 is used to resume the target and discarding > >> any signal that it may have stopped for. > >> GDB_SIGNAL_DEFAULT is used for (1). > >> > >> I realize the comments for target_resume say to not pass > >> GDB_SIGNAL_DEFAULT to it. But the name "target_continue_ptid" > >> with no option to choose between (1) and (2) > >> says to me "do what GDB_SIGNAL_DEFAULT" does. > > [...] > > For now, I think just documenting target_continue_ptid as > resuming with no signal is good enough. 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. btw, how about target_continue_with_no_signal (ptid_t ptid) ?