From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6985 invoked by alias); 5 Mar 2004 22:36:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6955 invoked from network); 5 Mar 2004 22:36:47 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Mar 2004 22:36:47 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id A77DC1A448D; Fri, 5 Mar 2004 17:31:16 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16456.65460.597233.331576@localhost.redhat.com> Date: Fri, 05 Mar 2004 22:36:00 -0000 To: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c: New patch solving gdb1291.exp (was Re: [RFA] Fix PR tdep/1291, SH prologue scanning bug) In-Reply-To: <20040225163336.GY1587@cygbert.vinschen.de> References: <200402192344.38974.fnf@ninemoons.com> <20040225163336.GY1587@cygbert.vinschen.de> X-SW-Source: 2004-03.o/txt/msg00113.txt Corinna Vinschen writes: > On Feb 19 23:44, Fred Fish wrote: > > This patch fixes the bug reported in PR 1291. It is based on the suggested > > patch included in the PR. I believe it is small enough to not need a > > copyright assignment, but recent events may have changed that. :-( > > > > -Fred > > > > 2004-02-19 Fred Fish > > > > Fix for PR tdep/1291 as suggested by inaba@src.ricoh.co.jp > > * sh-tdep.c (IS_MOV_R3): Rename to IS_MOV_IMM_R3 and fix pattern. > > (IS_ADD_R3SP): Rename to IS_ADD_R3_SP for consistency. > > (IS_MOVW_R1): New macro. > > (IS_MOVL_R1): New macro. > > (IS_SUB_R1_SP): New macro. > > (sh_analyze_prologue): Add r1_val local var and initialize to zero. > > Use IS_MOVW_R1, IS_MOVL_R1, and IS_SUB_R1_SP to recognize use of > > stack allocation via constant loaded into r1. > > I've looked into this one and found that there's a very simple patch > to solve that issue. Basically the evaluation of the memory address > to access in PC relative addressing was misbehaving. The below patch > evaluates the PC relative memory location now exactly according to the > descriptions of the PC relative addressing modes with 8 bit displacement > in the official SH documentation: > > FOO.w @(disp:8,PC): > > displacement = (instruction & 0xff) << 1; > address = (PC + 4) + displacement; > > FOO.l @(disp:8,PC): > > displacement = (instruction & 0xff) << 2; > address = ((PC & 0xfffffffc) + 4) + displacement; > > I checked the entire testsuite against sh2, sh2e, sh3, sh4 and sh4-nofpu. > In all cases, the FAIL count has been reduced by exactly one, the FAIL > from gdb1291.exp. > > Is that ok to checkin? > If this fixes PR/1291, it should refer to it in the changelog, and also the pr should be closed. otherwise ok. > > Corinna > > * sh-tdep.c (sh_analyze_prologue): Align PC relative addressing > to official documentation. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6985 invoked by alias); 5 Mar 2004 22:36:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6955 invoked from network); 5 Mar 2004 22:36:47 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Mar 2004 22:36:47 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id A77DC1A448D; Fri, 5 Mar 2004 17:31:16 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16456.65460.597233.331576@localhost.redhat.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 To: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c: New patch solving gdb1291.exp (was Re: [RFA] Fix PR tdep/1291, SH prologue scanning bug) In-Reply-To: <20040225163336.GY1587@cygbert.vinschen.de> References: <200402192344.38974.fnf@ninemoons.com> <20040225163336.GY1587@cygbert.vinschen.de> X-SW-Source: 2004-03/txt/msg00113.txt.bz2 Message-ID: <20040319000900._lw8hJNFlGcfw1SlyrG2HQSgh4fTxm0XcreYMP3Gis0@z> Corinna Vinschen writes: > On Feb 19 23:44, Fred Fish wrote: > > This patch fixes the bug reported in PR 1291. It is based on the suggested > > patch included in the PR. I believe it is small enough to not need a > > copyright assignment, but recent events may have changed that. :-( > > > > -Fred > > > > 2004-02-19 Fred Fish > > > > Fix for PR tdep/1291 as suggested by inaba@src.ricoh.co.jp > > * sh-tdep.c (IS_MOV_R3): Rename to IS_MOV_IMM_R3 and fix pattern. > > (IS_ADD_R3SP): Rename to IS_ADD_R3_SP for consistency. > > (IS_MOVW_R1): New macro. > > (IS_MOVL_R1): New macro. > > (IS_SUB_R1_SP): New macro. > > (sh_analyze_prologue): Add r1_val local var and initialize to zero. > > Use IS_MOVW_R1, IS_MOVL_R1, and IS_SUB_R1_SP to recognize use of > > stack allocation via constant loaded into r1. > > I've looked into this one and found that there's a very simple patch > to solve that issue. Basically the evaluation of the memory address > to access in PC relative addressing was misbehaving. The below patch > evaluates the PC relative memory location now exactly according to the > descriptions of the PC relative addressing modes with 8 bit displacement > in the official SH documentation: > > FOO.w @(disp:8,PC): > > displacement = (instruction & 0xff) << 1; > address = (PC + 4) + displacement; > > FOO.l @(disp:8,PC): > > displacement = (instruction & 0xff) << 2; > address = ((PC & 0xfffffffc) + 4) + displacement; > > I checked the entire testsuite against sh2, sh2e, sh3, sh4 and sh4-nofpu. > In all cases, the FAIL count has been reduced by exactly one, the FAIL > from gdb1291.exp. > > Is that ok to checkin? > If this fixes PR/1291, it should refer to it in the changelog, and also the pr should be closed. otherwise ok. > > Corinna > > * sh-tdep.c (sh_analyze_prologue): Align PC relative addressing > to official documentation. >