From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108475 invoked by alias); 28 Apr 2015 16:12:00 -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 108452 invoked by uid 89); 28 Apr 2015 16:11:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD 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-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Apr 2015 16:11:57 +0000 Received: by igdh15 with SMTP id h15so1876615igd.0 for ; Tue, 28 Apr 2015 09:11:55 -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=Ube9zL+R/NZlt7tKOQwyzYrEsM7UBZgKR/03teDPPH8=; b=JRaZLidMR7uewKrGJYkDW3NOd/drEWkOnv7fGbQADS5IJGC8PpCoCAhS+sB/15RWVF f22IiLNt9GLQoYJAw5Ja/p2fmEuWRsOMUXib3LBgkUoSWwWUpz/ISGu2CmpbB2bvSzyy EFYFz2sfVY+8w9Ik0JaIuDVwwi/GfGB4yILjT5VslNdRVqmhnKZfRs0ZB83/TRWGnwGa gMg86BwTv+/m0pL1Wb9As6bscIKbx6Dy+QTWJZnngsz7+APVpFmJPx6YHQySIIUgmmBx Z1IrE4YhV2AAaTBzJ1D0YKTHcU8Op3qul83p0m/YkcYdD408F0i43tV4O/chHEa7POAH bt3Q== X-Gm-Message-State: ALoCoQlpd3yBqMOMsnbNqV1jlozelLoJtOp+gNlLUQQrYVT9bB41K2u4QCnOOgBFSnnLh1dOisw0UUh6u71q+PD9g3bej6PI0K9u/73jIlKPXcv1+8ZP2MVAsYhS7bnUvbGP7LRVY5UdgdzUPmGA/xMSRWo7SzASZnqTsF3xriYOzRz1w3Db6i8= X-Received: by 10.182.28.99 with SMTP id a3mr9833410obh.18.1430237515485; Tue, 28 Apr 2015 09:11:55 -0700 (PDT) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id o5si1249043yhd.5.2015.04.28.09.11.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 09:11:55 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id EvvGJXdh.1; Tue, 28 Apr 2015 09:11:55 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21823.45386.375921.204343@ruffy2.mtv.corp.google.com> Date: Tue, 28 Apr 2015 20:28:00 -0000 To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3 07/17] Misc switch_back_to_stepped_thread cleanups In-Reply-To: <5537FEF1.7000100@redhat.com> References: <1429267521-21047-1-git-send-email-palves@redhat.com> <1429267521-21047-8-git-send-email-palves@redhat.com> <21815.12255.713123.668054@ruffy2.mtv.corp.google.com> <5537FEF1.7000100@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01055.txt.bz2 Pedro Alves writes: > On 04/22/2015 06:21 AM, Doug Evans wrote: > > Pedro Alves writes: > > > [...] it isn't ever correct to pass step=1 to target_resume > > > on software single-step targets [...] > > > > Sounds like a good thing to document in a comment or assert. > > Yeah, we were discussing adding an assertion on the gdbserver > side here: > > https://sourceware.org/ml/gdb-patches/2015-04/msg00232.html > > An assertion on the gdb side is complicated, and I'd rather that be > done separately. gdbarch_software_single_step_p() returning true > does not mean that we can't use hardware step. E.g., ppc installs > that hook for stepping past atomic regions. We can't assert based on > software single-step breakpoints inserted, as infrun.c uses those > even on targets that don't implement gdbarch_software_single_step_p. > We could add a new target_can_hardware_single_step method, which > ideally for remote targets would be based on the reply to the "vCont?" > probe packet, but gdbserver always includes "s" actions in the reply > even on targets that can't hardware step, and we can't just make it > not do that, since remote.c:remote_vcont_probe has: > > /* If s, S, c, and C are not all supported, we can't use vCont. Clearing > BUF will make packet_ok disable the packet. */ > if (!support_s || !support_S || !support_c || !support_C) > buf[0] = 0; > > so even if we fixed mainline, newer gdbserver against older gdb > would be broken... So we need something else or in addition (probably > based on qSupported). > > For comments, how about this? > > diff --git i/gdb/infrun.c w/gdb/infrun.c > index 0bf1274..fbe12ab 100644 > --- i/gdb/infrun.c > +++ w/gdb/infrun.c > @@ -5839,7 +5839,9 @@ switch_back_to_stepped_thread (struct execution_control_state *ecs) > return 0; > } > > -/* Is thread TP in the middle of single-stepping? */ > +/* Is thread TP in the middle of (software or hardware) > + single-stepping? (Note the result of this function must never be > + passed directly as target_resume's STEP parameter.) */ > > static int > currently_stepping (struct thread_info *tp) > diff --git i/gdb/target.h w/gdb/target.h > index 66bf91e..283f56f 100644 > --- i/gdb/target.h > +++ w/gdb/target.h > @@ -1254,8 +1254,8 @@ extern void target_detach (const char *, int); > extern void target_disconnect (const char *, int); > > /* Resume execution of the target process PTID (or a group of > - threads). STEP says whether to single-step or to run free; SIGGNAL > - is the signal to be given to the target, or GDB_SIGNAL_0 for no > + threads). STEP says whether to hardware single-step or to run free; > + SIGGNAL is the signal to be given to the target, or GDB_SIGNAL_0 for no > signal. The caller may not pass GDB_SIGNAL_DEFAULT. A specific > PTID means `step/resume only this process id'. A wildcard PTID > (all threads, or all threads of process) means `step/resume > > Thanks, > Pedro Alves Works for me. Thanks!