From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29008 invoked by alias); 22 Aug 2002 20:36:45 -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 29001 invoked from network); 22 Aug 2002 20:36:44 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 Aug 2002 20:36:44 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g7MKMCl16351 for ; Thu, 22 Aug 2002 16:22:13 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g7MKaZu17770; Thu, 22 Aug 2002 16:36:35 -0400 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g7MKaYe27406; Thu, 22 Aug 2002 13:36:34 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g7MKaXp24125; Thu, 22 Aug 2002 13:36:33 -0700 Date: Thu, 22 Aug 2002 13:41:00 -0000 From: Kevin Buettner Message-Id: <1020822203632.ZM24124@localhost.localdomain> In-Reply-To: Elena Zannoni "Re: [RFA] rs6000-tdep.c: more e500 support" (Aug 22, 4:02pm) References: <15717.9340.349019.324586@localhost.redhat.com> <1020822184853.ZM8312@localhost.localdomain> <15717.17245.600253.913162@localhost.redhat.com> To: Elena Zannoni , Kevin Buettner Subject: Re: [RFA] rs6000-tdep.c: more e500 support Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00710.txt.bz2 On Aug 22, 4:02pm, Elena Zannoni wrote: > 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 Okay, thanks for the explanation. > > > @@ -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. I would prefer that also. Kevin