From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116241 invoked by alias); 22 Feb 2017 10:15:39 -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 115607 invoked by uid 89); 22 Feb 2017 10:15:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=Starts X-HELO: mail-qt0-f193.google.com Received: from mail-qt0-f193.google.com (HELO mail-qt0-f193.google.com) (209.85.216.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Feb 2017 10:15:26 +0000 Received: by mail-qt0-f193.google.com with SMTP id n37so671455qtb.3 for ; Wed, 22 Feb 2017 02:15:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Jmp6by3Nr6UIkdOkZ7AGykOZFhuSLvFRTQu4NhrTodQ=; b=uCgwrh4AEIGZTHVitee/NSZBTGD9/ChyoZahEXA1/ZgKK017SNT5ztT/mEXvq9iGPg fXfvalHIIe/2+l2BTj0QJEiTYswE48j75eQ/H22t4rK2WiP9qs/o+0dGH1w48Ya1Xivd qbDablsjnrhgzhPbDpuvKwcdCQJCaOAHDmTO0EOslHRnF6c51ouMIGDD78WFRj7MQS1S KCqWXBMndND66FgdTiejUR9p6Gd66lnbTHcwUt6Gh0B+lipZRLySFGzvKkjoyyrtRj3e 1XV+FNsb26eB/2PjWry1i3rQhroxPxkw+eWEIcIJY9vLVMJPsGitf9aGZnBNJyXtdYt2 TC8w== X-Gm-Message-State: AMke39nvLyoHVstHdWnRheAMdtZ3GWjPFT4yy8vKQ93L9qhNYxu3rt/H/AsK6KN6U4kuGFlimkfgkzbhCUidqw== X-Received: by 10.200.41.7 with SMTP id y7mr1423471qty.109.1487758525278; Wed, 22 Feb 2017 02:15:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.140.194 with HTTP; Wed, 22 Feb 2017 02:15:24 -0800 (PST) In-Reply-To: <20161129120702.9490-2-antoine.tremblay@ericsson.com> References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20161129120702.9490-2-antoine.tremblay@ericsson.com> From: Yao Qi Date: Wed, 22 Feb 2017 10:15:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Avoid step-over infinite loop in GDBServer To: Antoine Tremblay Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00588.txt.bz2 On Tue, Nov 29, 2016 at 12:07 PM, Antoine Tremblay wrote: > Before this patch, GDBServer always executed a step-over if it found a > thread that needed one. > > This could be a problem in a situation exposed by non-stop-fair-events.exp > where the code and the breakpoint placement is like so: > > instruction A : has a single-step breakpoint installed for thread 1 and 2 > instruction B : has a single-step breakpoint installed for thread 3 > and is a branch to A. > Is instruction B following instruction A? Is it like .L1: nop b .L1 > In this particular case: > > - GDBServer stops on instruction A in thread 1. > - Deletes thread 1 single-step breakpoint. > - Starts a step-over of thread 1 to step-over the thread 2 breakpoint. > - GDBServer finishes a step-over and is at instruction B. > - GDBserver starts a step-over of thread 1 to step-over the thread 3 > breakpoint at instruction B. Why does GDBserver starts a step-over again? is it because need_step_over_p doing checks like this, if (breakpoint_here (pc) || fast_tracepoint_jump_here (pc)) { /* Don't step over a breakpoint that GDB expects to hit though. If the condition is being evaluated on the target's side and it evaluate to false, step over this breakpoint as well. */ if (gdb_breakpoint_here (pc) && gdb_condition_true_at_breakpoint (pc) && gdb_no_commands_at_breakpoint (pc)) { if (debug_threads) debug_printf ("Need step over [LWP %ld]? yes, but found" " GDB breakpoint at 0x%s; skipping step over\n", lwpid_of (thread), paddress (pc)); current_thread =3D saved_thread; return 0; } else { if (debug_threads) debug_printf ("Need step over [LWP %ld]? yes, " "found breakpoint at 0x%s\n", lwpid_of (thread), paddress (pc)); /* We've found an lwp that needs stepping over --- return 1 so that find_inferior stops looking. */ current_thread =3D saved_thread; return 1; } } there is a single step breakpoint on pc, and it is obviously not a gdb breakpoint, so 1 is returned. > - GDBServer stops on instuction A in thread 1. > - GDBServer is now in an infinite loop. > I am wondering can we take the information that we've already step over a breakpoint for thread A into need_step_over_p, if we see pc is on another single step breakpoint for thread B, don't do step over. --=20 Yao (=E9=BD=90=E5=B0=A7)