Message ID | 20161209120558.GF13661@E107787-LIN |
---|---|
State | New, archived |
Headers |
Received: (qmail 92867 invoked by alias); 9 Dec 2016 12:06:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 92850 invoked by uid 89); 9 Dec 2016 12:06:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy=antoine, Antoine, Feb, proceeds X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Dec 2016 12:06:17 +0000 Received: by mail-wm0-f65.google.com with SMTP id a20so3633735wme.2 for <gdb-patches@sourceware.org>; Fri, 09 Dec 2016 04:06:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=4Td11sb917jp4mo9phc4HNwgUTTK3A9u82CPK0icEIE=; b=BI4iIwjt9cs3tMdepS4lv6lOuFl8dbIttl5MZS6Q+BxlPLXMn4QKT7t5svgBAnMeMp 1RMSVdYc0GDaDE5Iyz+12fRZngCoG6mqvWE09ZSUJYqZacV1iIX/ZkIhjed/BAnGBsIF oG4tX9LAyITU81ko+KX2hxoJypPI9COOQOX2aLon6EKxkc9GiJwbmLE8Gx9uSGpAYpxf IUlTuVJxSwdxXfhZ0kJmUp2z7pTWuSiEXFf/5AP7bASpVPUFjzjkR4I1/omieSRk2YoL lAZsD5almQdWZ8PClAmNYi2b9C5L7OUO7Nh4Y7ywGy8LiXwphiK3F+av2bh2iYjA2Tc4 i/hg== X-Gm-Message-State: AKaTC00r8GVrj6ZJ4NnfYl+TYvLX3PI/lvIMQfMuFBheutuMJ1a8+m3o74Bloevv2Xxlzw== X-Received: by 10.28.194.135 with SMTP id s129mr6993253wmf.55.1481285174953; Fri, 09 Dec 2016 04:06:14 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id w7sm20203544wmd.24.2016.12.09.04.06.12 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 09 Dec 2016 04:06:14 -0800 (PST) Date: Fri, 9 Dec 2016 12:05:58 +0000 From: Yao Qi <qiyaoltc@gmail.com> To: Antoine Tremblay <antoine.tremblay@ericsson.com> Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] Fix inferior memory reading in GDBServer for arm/aarch32. Message-ID: <20161209120558.GF13661@E107787-LIN> References: <20161128122758.7762-1-antoine.tremblay@ericsson.com> <20161201144401.GA19289@E107787-LIN> <wwoky3zzwtwx.fsf@ericsson.com> <wwokwpfjwsop.fsf@ericsson.com> <wwoktwanwrlo.fsf@ericsson.com> <wwokshq7wmhb.fsf@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <wwokshq7wmhb.fsf@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes |
Commit Message
Yao Qi
Dec. 9, 2016, 12:05 p.m. UTC
On 16-12-01 13:09:56, Antoine Tremblay wrote: > > After some more thought, it can happen even with current code too that > single step breakpoints are installed without a step-over. > > Consider this situation: > > In non-stop: > > the user issues: > > thread 1 > step& > thread 2 > step& > thread 3 > step& > > In a similar way as non-stop-fair-events.exp (threads are looping). > > GDBServer: > > linux_resume is called > GDBServer has pending events, > threads are not resumed and single-step breakpoint for thread 1 not installed. > > linux_wait_1 is called with a pending event on thread 2 at pc A > GDBServer handles the event and calls proceed_all_lwps > This calls proceed_one_lwp and installs single-step breakpoints on all > the threads that need one. > > Now since thread 1 needs to install a single-step breakpoint and is at pc B > (different than thread 2), a step-over is not initiated and get_next_pc > is called to figure out the next instruction from pc B. > > However it may just be that thread 3 as a single step breakpoint at pc > B. And thus get_next_pc fails. > > This situation is tested with non-stop-fair-events.exp. > > Sorry for the confusion, you can consider only the two last replies as > valid. This helps understanding the problem, and helps me recalling one patch in my tree, but I didn't submit it (I can't remember why). Single-step breakpoints are installed in proceed_one_lwp for each thread. GDBserver proceeds two threads for resume_step, as requested by GDB, and the thread proceeded later may see the single-step breakpoints installed for the thread proceeded just now. Please add these explanations to the commit log.
diff --git a/gdb/gdbserver/linux-arm-low.c b/gdb/gdbserver/linux-arm-low.c index ed9b356..a62904a 100644 --- a/gdb/gdbserver/linux-arm-low.c +++ b/gdb/gdbserver/linux-arm-low.c @@ -263,7 +263,7 @@ get_next_pcs_read_memory_unsigned_integer (CORE_ADDR memaddr, ULONGEST res; res = 0; - (*the_target->read_memory) (memaddr, (unsigned char *) &res, len); + read_inferior_memory (memaddr, (unsigned char *) &res, len); return res; }