From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00262.txt.bz2 Antoine Tremblay writes: > + > +/* Get the raw next possible addresses. PC in next_pcs is the current p= rogram > + 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 memo= ry > + 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 =3D self->byte_order; > + unsigned long pc_val; > + unsigned long this_instr =3D 0; > + unsigned long status; > + CORE_ADDR nextpc; > + struct regcache *regcache =3D self->regcache; > + VEC (CORE_ADDR) *next_pcs =3D NULL; > + > + pc_val =3D (unsigned long) pc; > + this_instr =3D self->ops->read_mem_uint (pc, 4, byte_order); ^^^^^^^^^^ > - > -/* Get the raw next address. PC is the current program counter, in=20 > - FRAME, which is assumed to be executing in ARM mode. > - > - The value returned has the execution state of the next instruction=20 > - 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 memo= ry > - address. */ > - > -static CORE_ADDR > -arm_get_next_pc_raw (struct regcache *regcache, CORE_ADDR pc) > -{ > - struct gdbarch *gdbarch =3D get_regcache_arch (regcache); > - enum bfd_endian byte_order =3D gdbarch_byte_order (gdbarch); > - enum bfd_endian byte_order_for_code =3D gdbarch_byte_order_for_code (g= dbarch); > - unsigned long pc_val; > - unsigned long this_instr; > - unsigned long status; > - CORE_ADDR nextpc; > - > - pc_val =3D (unsigned long) pc; > - this_instr =3D read_memory_unsigned_integer (pc, 4, byte_order_for_cod= e); ^^^^^^^^^^^^^^^^^^^ 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. --=20 Yao (=E9=BD=90=E5=B0=A7) =46rom 7b73761dfbecfdf0779d0a3b9e4ea64aed9a9141 Mon Sep 17 00:00:00 2001 From: Yao Qi Date: Wed, 13 Jan 2016 15:00:39 +0000 Subject: [PATCH] Read instruction with byte_order_for_code When reading instruction, we should use byte_order_for_code instead of byte_order. gdb: 2016-01-13 Yao Qi * arch/arm-get-next-pcs.c (arm_get_next_pcs_raw): Use byte_order_for_code to read instruction. 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 =3D self->byte_order; + int byte_order_for_code =3D self->byte_order_for_code; unsigned long pc_val; unsigned long this_instr =3D 0; unsigned long status; @@ -653,7 +654,7 @@ arm_get_next_pcs_raw (struct arm_get_next_pcs *self) VEC (CORE_ADDR) *next_pcs =3D NULL; =20 pc_val =3D (unsigned long) pc; - this_instr =3D self->ops->read_mem_uint (pc, 4, byte_order); + this_instr =3D self->ops->read_mem_uint (pc, 4, byte_order_for_code); =20 status =3D regcache_raw_get_unsigned (regcache, ARM_PS_REGNUM); nextpc =3D (CORE_ADDR) (pc_val + 4); /* Default case */