From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5016 invoked by alias); 22 Aug 2002 20:04:32 -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 4977 invoked from network); 22 Aug 2002 20:04:31 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 22 Aug 2002 20:04:31 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id BED5210DCC; Thu, 22 Aug 2002 16:02:37 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15717.17245.600253.913162@localhost.redhat.com> Date: Thu, 22 Aug 2002 13:10:00 -0000 To: Kevin Buettner Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] rs6000-tdep.c: more e500 support In-Reply-To: <1020822184853.ZM8312@localhost.localdomain> References: <15717.9340.349019.324586@localhost.redhat.com> <1020822184853.ZM8312@localhost.localdomain> X-SW-Source: 2002-08/txt/msg00707.txt.bz2 Kevin Buettner writes: > On Aug 22, 1:50pm, Elena Zannoni wrote: > > > @@ -647,7 +654,7 @@ skip_prologue (CORE_ADDR pc, CORE_ADDR l > > else if ((op & 0xfc0007fe) == 0x7c000378 && /* mr(.) Rx,Ry */ > > (((op >> 21) & 31) >= 3) && /* R3 >= Ry >= R10 */ > > (((op >> 21) & 31) <= 10) && > > - (((op >> 16) & 31) >= fdata->saved_gpr)) /* Rx: local var reg */ > > + ((long) ((op >> 16) & 31) >= fdata->saved_gpr)) /* Rx: local var reg */ > > { > > continue; > > > > Why is the cast needed above? Signed & unsigend comparisons, when saved_gpr is -1: op is unsigned long, while saved_gpr is an int I was running into this: (gdb) p (unsigned long) 0 > (int) -1 $3 = 0 the cast makes it work. I could have changed the type of op, but I was afraid I would break a bunch of other things. (gdb) p (long) 0 > (int) -1 $4 = 1 > > > @@ -754,6 +763,100 @@ skip_prologue (CORE_ADDR pc, CORE_ADDR l > > } > > } > > /* End AltiVec related instructions. */ > > + > > + /* Start BookE related instructions. */ > > + /* Store gen register S at (r31+uimm). > > + Any register less than r13 is volatile, so we don't care. */ > > + /* 000100 sssss 11111 iiiii 01100100001 */ > > + else if ((op & 0xfc1f07ff) == 0x101f0321) /* evstdd Rs,uimm(R31) */ > > Hmm... it looks like BookE is using 6 for its primary opcode (which are > the most significant 6 bits). I wonder if this could cause conflicts > with other cores which also extend the base PPC instruction set. > > A quick Google search reveals: > > http://sources.redhat.com/ml/binutils/2001-10/msg00186.html > > So apparently there can be conflicts. It's not clear to me if there > are conflicts for the instructions that we care about, but I wonder > if it might not be better to add a conjunct which restricts these tests > to the BookE architecture. (Maybe it'd be a good idea to squirrel > away the v->arch and v->mach values from rs6000_gdbarch_init() into > the gdbarch_tdep struct. I guess you could also check to see if > tdep->ppc_ev0_regnum is not -1.) > Yes, conflicts also with Altivec instructions. I would prefer to save the architecture & machine pair, rather than check the registers. Elena > Kevin