From patchwork Fri Jan 27 15:01:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 19045 Received: (qmail 114032 invoked by alias); 27 Jan 2017 15:01:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 114018 invoked by uid 89); 27 Jan 2017 15:01:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=armv7, ARMv7, invented, H*RU:74.125.82.65 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, 27 Jan 2017 15:01:45 +0000 Received: by mail-wm0-f65.google.com with SMTP id d140so59069407wmd.2 for ; Fri, 27 Jan 2017 07:01:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=9XcLqjQzyg6qPxaMXfa0VojvrfMhSw1EqTR0ahvGn60=; b=HN+lnOI4d+ULyctGS2oNwnoAQaYPTVv6txJqd0x93z7G4nqFO6++wbT9q9htvEh7yC 66n8Mj1PKiZvHzfB7DwXKagJgwrNgzF07CVaQwRuQRYSXL+NPjOGLyhhO1wX4L1D6l6R IZTUD8hrv1qWOF6PI3M9Laefb5+9mnN8nGu+mB2elmu2msOX1VCPyiaYOslfhMHYpNqH H7DHojKpYNtqZIw83zSlvw1qPpMc6JWyud4DBpJdcwcw+AWm4w18puh5EpZLoBpdk4Pj Db2cbPl12+qiFyc1VYkUQ5tu/1csdUxVdXcNiIi1/45AuT08rr/732j/XZdQ/H6fn91L 5iMg== X-Gm-Message-State: AIkVDXKclzqKuJymeS4KHvINDvWxAMd0qKRfgNogI/BhE1Zc2xGdrLf/WDD/8fE7c1OWrQ== X-Received: by 10.28.111.78 with SMTP id k75mr3668223wmc.71.1485529303030; Fri, 27 Jan 2017 07:01:43 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id d42sm8319467wrd.7.2017.01.27.07.01.41 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 27 Jan 2017 07:01:42 -0800 (PST) Date: Fri, 27 Jan 2017 15:01:39 +0000 From: Yao Qi To: Antoine Tremblay Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping Message-ID: <20170127150139.GB24676@E107787-LIN> References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161129120702.9490-1-antoine.tremblay@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On 16-11-29 07:07:01, Antoine Tremblay wrote: > ** Note these patches depend on: > https://sourceware.org/ml/gdb-patches/2016-11/msg00914.html > > Before, installing single-step breakpoints was done in proceed_one_lwp as > each thread was started. > > This caused a problem on ARM, which is the only architecture using > software single-step on which it is not safe to modify an instruction > to insert a breakpoint in one thread while the other threads are running. > See the architecture manual section "A3.5.4 Concurrent modification and > execution of instructions": > > "The ARMv7 architecture limits the set of instructions that can be > executed by one thread of execution as they are being modified by another > thread of execution without requiring explicit synchronization. Except > for the instructions identified in this section, the effect of the > concurrent modification and execution of an instruction is UNPREDICTABLE > ." This doesn't apply to ptrace. PTRACE_POKETEXT on a word aligned address is atomic, so threads observe the coherent result, either breakpoint instruction or the original instruction. We don't see any fails in -marm mode, do we? In -mthumb mode, breakpoint can be 16-bit or 32-bit, but GDBserver still PTRACE_POKETEXT on a word aligned address (in linux-low.c:linux_write_memory) and write a word each time. It should be atomic, however, if the 32-bit thumb-2 instruction is 2-byte aligned, we end up two PTRACE_POKETEXT, which is non-atomic. That is the root cause of the problem, AFAICS. 32-bit thumb-2 breakpoint was invented for single step 32-bit thumb-2 instruction in IT block, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-January/007488.html but we can use 16-bit thumb breakpoint instruction anywhere else. If I force GDBserver to use 16-bit thumb breakpoint instruction even on 32-bit thumb-2 instruction, I can't see any fails in schedlock.exp anymore! See the patch below. Out of IT block, we can use 16-bit thumb breakpoint for any thumb code. In IT block, we can use 16-bit thumb breakpoint for 16-bit instruction, and 32-bit thumb-2 breakpoint for 4-byte aligned 32-bit thumb-2 instruction. However, we can not use either 16-bit or 32-bit breakpoint for 2-byte aligned 32-bit thumb-2 instruction in IT block. The reason we can't use 16-bit breakpoint on a 32-bit instruction in IT block is that 16-bit breakpoint instruction makes the second half of 32-bit instruction to another different 16-bit instruction, and the 16-bit breakpoint instruction may not be executed at all, so the second half of instruction may be executed, and the result is completely unknown. GDB sets two breakpoints on two branches, "if" branch and "else" branch, because GDB doesn't know how does the instruction to be executed affect the flag. /* There are conditional instructions after this one. If this instruction modifies the flags, then we can not predict what the next executed instruction will be. Fortunately, this instruction is architecturally forbidden to branch; we know it will fall through. Start by skipping past it. */ GDB/GDBserver has to emulate the instruction on how does it affect the flag, and only insert the breakpoint on the "true" branch. Since the target instruction will be definitely executed, we can safely use 16-bit breakpoint instruction. diff --git a/gdb/gdbserver/linux-aarch32-low.c b/gdb/gdbserver/linux-aarch32-low.c index 2b710ba..789e0e6 100644 --- a/gdb/gdbserver/linux-aarch32-low.c +++ b/gdb/gdbserver/linux-aarch32-low.c @@ -243,7 +243,7 @@ arm_breakpoint_kind_from_pc (CORE_ADDR *pcptr) target_read_memory (*pcptr, (gdb_byte *) &inst1, 2); if (thumb_insn_size (inst1) == 4) - return ARM_BP_KIND_THUMB2; + return ARM_BP_KIND_THUMB; } return ARM_BP_KIND_THUMB; }