From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-112225-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 10658 invoked by alias); 7 May 2014 08:01:09 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.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
Received: (qmail 10639 invoked by uid 89); 7 May 2014 08:01:08 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-ig0-f171.google.com
Received: from mail-ig0-f171.google.com (HELO mail-ig0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 May 2014 08:01:07 +0000
Received: by mail-ig0-f171.google.com with SMTP id c1so7365491igq.16        for <gdb-patches@sourceware.org>; Wed, 07 May 2014 01:01:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20130820;        h=x-gm-message-state:mime-version:in-reply-to:references:date         :message-id:subject:from:to:cc:content-type         :content-transfer-encoding;        bh=k8l6ITfGOEZkRX61QYVADMcl0e7NitGS9E94KARelUQ=;        b=TN6hG5vz0NDPbR+mEHsaVznphI1q0UlGfkmM0YA7hAmwc/nxxhvl4Pi8KDsg/BKPyr         SzG/9qHI6vV4bJBlfWAB64hNo7dtRHIZbjzJpq5DbvYxmPydseLxZqbvJ6O23t+n+Nzt         1wAGW2iaXie2XlNqL3PmGeh5xqRFpLIUBwGU54OsBst3603hI9gzBgnXZakSVz+eu2EJ         sAs6xiIUAQwWs43zlDQiOR6+yGebW8cAwU6fvC5M2n3FhKj8Lq09EmDZkBI2n/Zv73oU         M4g9ey9dlvGkI1SVosGtckHz+5nFZgjLxNzyqxvtYKvyf94s8guCAvbXX4c8A4TEUh8H         4gvg==
X-Gm-Message-State: ALoCoQnllyqQ3hYH28uKvcqIQ4u6smT+uSKy07/OdL3A1zZkCY0ZbigNXqbZWrzJytnv4iPYbxKx
MIME-Version: 1.0
X-Received: by 10.50.79.202 with SMTP id l10mr4608480igx.23.1399449666227; Wed, 07 May 2014 01:01:06 -0700 (PDT)
Received: by 10.64.14.33 with HTTP; Wed, 7 May 2014 01:01:06 -0700 (PDT)
In-Reply-To: <1399448485-1740-1-git-send-email-tmirza@codesourcery.com>
References: <1399448485-1740-1-git-send-email-tmirza@codesourcery.com>
Date: Wed, 07 May 2014 08:01:00 -0000
Message-ID: <CANu=DmgMWP=dr=9xxQxcnFC-99M-BjdZa9JQa8vHM_w8Ythkxg@mail.gmail.com>
Subject: Re: [PATCH] Fix prologue analysis for ldr.w and ldrd instruction
From: Will Newton <will.newton@linaro.org>
To: Taimoor Mirza <tmirza@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2014-05/txt/msg00063.txt.bz2

On 7 May 2014 08:41, Taimoor Mirza <tmirza@codesourcery.com> wrote:
> Hi Guys,
>
> We experienced a problem while debugging startup code on Cortex-M targets=
 (LPC4350 and ATSAM3UEK). On stepping through the code, GDB was throwing "i=
nvalid memory access" error. We found out that problem
> is coming because of wrong offset calculation for ldr.w and ldrd instruct=
ion during prologue analysis in thumb-mode. Below is problematic code in *t=
humb_analyze_prologue* function:
>
> else if ((insn & 0xff7f) =3D=3D 0xf85f)    /* ldr.w Rt,<label> */
>         {
>           /* Constant pool loads.  */
>           unsigned int constant;
>           CORE_ADDR loc;
>
>           offset =3D bits (insn, 0, 11);
>           if (insn & 0x0080)
>         loc =3D start + 4 + offset;
>           else
>         loc =3D start + 4 - offset;
>
>           constant =3D read_memory_unsigned_integer (loc, 4, byte_order);
>           regs[bits (inst2, 12, 15)] =3D pv_constant (constant);
>         }
>
> The problem is at line *offset =3D bits (insn, 0, 11);* where it is obtai=
ning offset from first two bytes of instruction that contain opcode of ldr.=
w instruction. As per Cortex-M reference manual and BFD code, it should be:
>
> offset =3D bits (inst2, 0, 11);
>
> inst2 contains next two bytes of ldr.w instruction and it is correctly us=
ed to get register information. Similarly inst2 should be used to obtain of=
fset. Similar problem exists in ldrd instruction's offset calculation. Belo=
w patch provides fix of this problem. Is it OK?
>
> Thanks,
> Taimoor
>
> 2014-05-06  Taimoor Mirza  <tmirza@codesourcery.com>
>
>         gdb/
>         * arm-tdep.c (thumb_analyze_prologue): Fix offset calculation for
>         ldr.w and ldrd instructions.
> ---
>  gdb/arm-tdep.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> index e3b1c3d..7271777 100644
> --- a/gdb/arm-tdep.c
> +++ b/gdb/arm-tdep.c
> @@ -1071,7 +1071,7 @@ thumb_analyze_prologue (struct gdbarch *gdbarch,
>               unsigned int constant;
>               CORE_ADDR loc;
>
> -             offset =3D bits (insn, 0, 11);
> +             offset =3D bits (inst2, 0, 11);
>               if (insn & 0x0080)
>                 loc =3D start + 4 + offset;
>               else
> @@ -1087,7 +1087,7 @@ thumb_analyze_prologue (struct gdbarch *gdbarch,
>               unsigned int constant;
>               CORE_ADDR loc;
>
> -             offset =3D bits (insn, 0, 7) << 2;
> +             offset =3D bits (inst2, 0, 7) << 2;
>               if (insn & 0x0080)
>                 loc =3D start + 4 + offset;
>               else

This looks good to me, assuming the testsuite was run with no regressions.

--=20
Will Newton
Toolchain Working Group, Linaro