From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42674 invoked by alias); 22 Apr 2015 04:25:05 -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 42664 invoked by uid 89); 22 Apr 2015 04:25:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 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-qc0-f202.google.com Received: from mail-qc0-f202.google.com (HELO mail-qc0-f202.google.com) (209.85.216.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 22 Apr 2015 04:25:02 +0000 Received: by qcrw7 with SMTP id w7so4859066qcr.1 for ; Tue, 21 Apr 2015 21:25:00 -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=rRcfOqFZO/2odCY+ylh+2Vy/luNqOq0fi5iF917fTi8=; b=dYWRBhkcVn96mKtonZY9yMbeA1hQO5kUmdXgLzoEsb4NrUrCcZZMQbzlD7Azad3dn8 PnBm5F+xUP25+IG813liA3K+Y562G+rxIF6hlgAqpYs5LeV+DFaHiLbNiOYGy7QlBy8t O4KirNbbNorrJ0wBYbSTv23xTD701eEIdUipN5dnaGgh+ooqqbN2Nm9LXYp1FAgXaEeO KrRoAIfYpnrHhIfL0koayHu2i4Q2S+JwgLOqdnRNfqODe8B3yrDdCz9/hY/SH2bvBksh yrLraBlo4O2nYOfYZEfQPUJrh8W9t6YT/GkSnIKZwiUswQpe6mMGlMv0D095z54Yy93Q h1hQ== X-Gm-Message-State: ALoCoQngsAEo2GEExdJFOoOmAcP3la7PWiRuKFlwOnwbK/bDQYw5SW7hNxLpdBq+pnKI57Tv1rM6DPZ0dd/BbqgsXTRovIjVAElz0M9vKmGvUoH+qIQzhtdkmR9FbZxxvP0+ijaeqZtesZmzr3PRCAN1HRQWQoy1iwnM+MYWkP/o8SyXu9fiTc8= X-Received: by 10.236.44.101 with SMTP id m65mr34528239yhb.46.1429676700392; Tue, 21 Apr 2015 21:25:00 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id x25si372527yha.2.2015.04.21.21.24.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 21:25:00 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTP id ZyTnjfBz.1; Tue, 21 Apr 2015 21:25:00 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21815.8859.290139.116294@ruffy2.mtv.corp.google.com> Date: Wed, 22 Apr 2015 04:25:00 -0000 To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3 05/17] Embed the pending step-over chain in thread_info objects In-Reply-To: <1429267521-21047-6-git-send-email-palves@redhat.com> References: <1429267521-21047-1-git-send-email-palves@redhat.com> <1429267521-21047-6-git-send-email-palves@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00810.txt.bz2 Pedro Alves writes: > In order to teach non-stop mode to do in-line step-overs (pause all > threads, remove breakpoint, single-step, reinsert breakpoint, restart > threads), we'll need to be able to queue in-line step over requests, > much like we queue displaced stepping (out-of-line) requests. > Actually, the queue should be the same -- threads wait for their turn > to step past something (breakpoint, watchpoint), doesn't matter what > technique we end up using when the step over actually starts. > > I found that the queue management ends up simpler and more efficient > if embedded in the thread objects themselves. This commit converts > the existing displaced stepping queue to that. Later patches will > make the in-line step-overs code paths use it too. > > gdb/ChangeLog: > 2015-04-17 Pedro Alves > > * gdbthread.h (struct thread_info) step_over_next>: New fields. > (thread_step_over_chain_enqueue, thread_step_over_chain_remove) > (thread_step_over_chain_next, thread_is_in_step_over_chain): New > declarations. > * infrun.c (struct displaced_step_request): Delete. > (struct displaced_step_inferior_state) : > Delete field. > (displaced_step_in_progress): New function. > (displaced_step_prepare): Assert that trap_expected is set. Use > thread_step_over_chain_enqueue. Split starting a new displaced > step to ... > (start_step_over): ... this new function. > (resume): Assert the thread isn't waiting for a step over already. > (proceed): Assert the thread isn't waiting for a step over > already. > (infrun_thread_stop_requested): Adjust to remove threads from the > embedded step-over chain. > (handle_inferior_event) : Call start_step_over after > displaced_step_fixup. > (handle_signal_stop): Call start_step_over after > displaced_step_fixup. > * infrun.h (step_over_queue_head): New declaration. > * thread.c (step_over_chain_enqueue, step_over_chain_remove) > (thread_step_over_chain_next, thread_is_in_step_over_chain) > (thread_step_over_chain_enqueue) > (thread_step_over_chain_remove): New functions. > (delete_thread_1): Remove thread from the step-over chain. > > v3: > > More comments. The step-over chain is now a global instead of > being per-inferior. Previous versions had actually broken > multiple-processes displaced stepping at the same time. Added new > thread_is_in_step_over_chain predicate, and new > thread_step_over_chain_next helper function. Should make reading > the code a bit easier (following patches adjusted too). >... > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 534ecef..f325a53 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c >... > @@ -1855,24 +1842,44 @@ displaced_step_fixup (ptid_t event_ptid, enum gdb_signal signal) > do_cleanups (old_cleanups); > > displaced->step_ptid = null_ptid; > +} > > - /* Are there any pending displaced stepping requests? If so, run > - one now. Leave the state object around, since we're likely to > - need it again soon. */ > - while (displaced->step_request_queue) > +/* Are there any pending step-over requests? If so, run one now. */ Hi. Nit: IIUC "run one now" should read "run all we can now". > + > +static void > +start_step_over (void) > +{ >...