From patchwork Wed Jan 13 16:13:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 10359 Received: (qmail 50242 invoked by alias); 13 Jan 2016 16:13:16 -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 50180 invoked by uid 89); 13 Jan 2016 16:13:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:209.85.220.66, Hx-spam-relays-external:209.85.220.66, VEC X-HELO: mail-pa0-f66.google.com Received: from mail-pa0-f66.google.com (HELO mail-pa0-f66.google.com) (209.85.220.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 13 Jan 2016 16:13:13 +0000 Received: by mail-pa0-f66.google.com with SMTP id gi1so34532675pac.2 for ; Wed, 13 Jan 2016 08:13:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=9tcJIa1ikFbJ7T/iSsgwQX3lnvjZLYjCo21ixRNXCgI=; b=RtZryMaX+63mCXAuIN/3j/5w5h56eFuXnUATPrxERi0o5ij2mCqRJCVhPNkrc6CevI Lys2iT4usIxzW1NzfuKpLlGXkoWRu0zF3dODxjAN2AxdoFI+K8GsxYQEOEslbWfOz3cq njVxmNozOK9gGd8BRRNTyF+KJnoh4H4gs/7tUvWIF2YR6/PaCGdRNnZhy2i4EOxALAO7 GEnebkWh77ZxGTte9WZbiJN6J9DX9bTGlXBv8R1OSQkQpTAR3gMkKfKuAlCSAT7zLF4g diHul82kRNr9jnVpK0jU3QTf7aMNACCXSPXmKTeqsridpK6fKb28IomHt5EiJyZI8JXM debQ== X-Gm-Message-State: ALoCoQnQo/JG/NIJaZSr+dw2XDcqwRFAwVLGPGJmqBTK88a1tJAjZT2yn47es3hilOQ6EJUkiTM7BYCRMPkFcm9JtVAwR8bXOA== X-Received: by 10.66.101.36 with SMTP id fd4mr200666341pab.76.1452701591651; Wed, 13 Jan 2016 08:13:11 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id w82sm3553670pfi.95.2016.01.13.08.13.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 13 Jan 2016 08:13:10 -0800 (PST) From: Yao Qi To: Antoine Tremblay Cc: Subject: Re: [PATCH v8 5/7] Support software single step on ARM in GDBServer References: <1450361684-29536-1-git-send-email-antoine.tremblay@ericsson.com> <1450361684-29536-6-git-send-email-antoine.tremblay@ericsson.com> Date: Wed, 13 Jan 2016 16:13:00 +0000 In-Reply-To: <1450361684-29536-6-git-send-email-antoine.tremblay@ericsson.com> (Antoine Tremblay's message of "Thu, 17 Dec 2015 09:14:42 -0500") Message-ID: <86io2xv4oj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Antoine Tremblay writes: > + > +/* Get the raw next possible addresses. PC in next_pcs is the current program > + counter, which is assumed to be executing in ARM mode. > + > + The values returned have the execution state of the next instruction > + encoded in it. Use IS_THUMB_ADDR () to see whether the instruction is > + in Thumb-State, and gdbarch_addr_bits_remove () to get the plain memory > + address in GDB and arm_addr_bits_remove in GDBServer. */ > + > +VEC (CORE_ADDR) * > +arm_get_next_pcs_raw (struct arm_get_next_pcs *self, > + CORE_ADDR pc) > +{ > + int byte_order = self->byte_order; > + unsigned long pc_val; > + unsigned long this_instr = 0; > + unsigned long status; > + CORE_ADDR nextpc; > + struct regcache *regcache = self->regcache; > + VEC (CORE_ADDR) *next_pcs = NULL; > + > + pc_val = (unsigned long) pc; > + this_instr = self->ops->read_mem_uint (pc, 4, byte_order); ^^^^^^^^^^ > - > -/* Get the raw next address. PC is the current program counter, in > - FRAME, which is assumed to be executing in ARM mode. > - > - The value returned has the execution state of the next instruction > - encoded in it. Use IS_THUMB_ADDR () to see whether the instruction is > - in Thumb-State, and gdbarch_addr_bits_remove () to get the plain memory > - address. */ > - > -static CORE_ADDR > -arm_get_next_pc_raw (struct regcache *regcache, CORE_ADDR pc) > -{ > - struct gdbarch *gdbarch = get_regcache_arch (regcache); > - enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > - enum bfd_endian byte_order_for_code = gdbarch_byte_order_for_code (gdbarch); > - unsigned long pc_val; > - unsigned long this_instr; > - unsigned long status; > - CORE_ADDR nextpc; > - > - pc_val = (unsigned long) pc; > - this_instr = read_memory_unsigned_integer (pc, 4, byte_order_for_code); ^^^^^^^^^^^^^^^^^^^ The code change above introduces a bug as I see. The original code uses byte_order_for_code which is right to me, but it becomes byte_order after the change. Patch below fixes it. diff --git a/gdb/arch/arm-get-next-pcs.c b/gdb/arch/arm-get-next-pcs.c index f9c2592..a30916a 100644 --- a/gdb/arch/arm-get-next-pcs.c +++ b/gdb/arch/arm-get-next-pcs.c @@ -644,6 +644,7 @@ static VEC (CORE_ADDR) * arm_get_next_pcs_raw (struct arm_get_next_pcs *self) { int byte_order = self->byte_order; + int byte_order_for_code = self->byte_order_for_code; unsigned long pc_val; unsigned long this_instr = 0; unsigned long status; @@ -653,7 +654,7 @@ arm_get_next_pcs_raw (struct arm_get_next_pcs *self) VEC (CORE_ADDR) *next_pcs = NULL; pc_val = (unsigned long) pc; - this_instr = self->ops->read_mem_uint (pc, 4, byte_order); + this_instr = self->ops->read_mem_uint (pc, 4, byte_order_for_code); status = regcache_raw_get_unsigned (regcache, ARM_PS_REGNUM); nextpc = (CORE_ADDR) (pc_val + 4); /* Default case */