From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32041 invoked by alias); 6 Oct 2007 16:01:38 -0000 Received: (qmail 32031 invoked by uid 22791); 6 Oct 2007 16:01:35 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Oct 2007 16:01:31 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 3CAED32C094 for ; Sat, 6 Oct 2007 12:42:51 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l96G1TEh3182676 for ; Sat, 6 Oct 2007 13:01:29 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l96G1Seo013577 for ; Sat, 6 Oct 2007 13:01:28 -0300 Received: from hactar.local ([9.8.4.86]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l96G1SAx013572; Sat, 6 Oct 2007 13:01:28 -0300 Subject: Re: [rfc] Use target descriptions for PowerPC From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org In-Reply-To: <20071005163754.GA26041@caradoc.them.org> References: <20071005163754.GA26041@caradoc.them.org> Content-Type: text/plain Date: Sat, 06 Oct 2007 16:01:00 -0000 Message-Id: <1191686484.18959.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2007-10/txt/msg00089.txt.bz2 Hi Daniel, A few more comments, in the hope they can be useful. On Fri, 2007-10-05 at 12:37 -0400, Daniel Jacobowitz wrote: > -/* PowerPC UISA - a PPC processor as viewed by user-level code. A UISA-only > - view of the PowerPC. */ > -static const struct reg registers_powerpc[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_ALTIVEC_REGS > -}; > - > -/* IBM PowerPC 403. > - > - Some notes about the "tcr" special-purpose register: > - - On the 403 and 403GC, SPR 986 is named "tcr", and it controls the > - 403's programmable interval timer, fixed interval timer, and > - watchdog timer. > - - On the 602, SPR 984 is named "tcr", and it controls the 602's > - watchdog timer, and nothing else. > - > - Some of the fields are similar between the two, but they're not > - compatible with each other. Since the two variants have different > - registers, with different numbers, but the same name, we can't > - splice the register name to get the SPR number. */ > -static const struct reg registers_403[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(icdbdr), S(esr), S(dear), S(evpr), > - /* 123 */ S(cdbcr), S(tsr), SN4(tcr, ppc_spr_403_tcr), S(pit), > - /* 127 */ S(tbhi), S(tblo), S(srr2), S(srr3), > - /* 131 */ S(dbsr), S(dbcr), S(iac1), S(iac2), > - /* 135 */ S(dac1), S(dac2), S(dccr), S(iccr), > - /* 139 */ S(pbl1), S(pbu1), S(pbl2), S(pbu2) > -}; > - > -/* Motorola PowerPC 860 or 850. */ > -static const struct reg registers_860[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(eie), S(eid), S(nri), S(cmpa), > - /* 123 */ S(cmpb), S(cmpc), S(cmpd), S(icr), > - /* 127 */ S(der), S(counta), S(countb), S(cmpe), > - /* 131 */ S(cmpf), S(cmpg), S(cmph), S(lctrl1), > - /* 135 */ S(lctrl2), S(ictrl), S(bar), S(ic_cst), > - /* 139 */ S(ic_adr), S(ic_dat), S(dc_cst), S(dc_adr), > - /* 143 */ S(dc_dat), S(dpdr), S(dpir), S(immr), > - /* 147 */ S(mi_ctr), S(mi_ap), S(mi_epn), S(mi_twc), > - /* 151 */ S(mi_rpn), S(md_ctr), S(m_casid), S(md_ap), > - /* 155 */ S(md_epn), S(m_twb), S(md_twc), S(md_rpn), > - /* 159 */ S(m_tw), S(mi_dbcam), S(mi_dbram0), S(mi_dbram1), > - /* 163 */ S(md_dbcam), S(md_dbram0), S(md_dbram1) > -}; > - > -/* Motorola PowerPC 601. Note that the 601 has different register numbers > - for reading and writing RTCU and RTCL. However, how one reads and writes a > - register is the stub's problem. */ > -static const struct reg registers_601[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(hid0), S(hid1), S(iabr), S(dabr), > - /* 123 */ S(pir), S(mq), S(rtcu), S(rtcl) > -}; > - > -/* Motorola PowerPC 602. > - See the notes under the 403 about 'tcr'. */ > -static const struct reg registers_602[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(hid0), S(hid1), S(iabr), R0, > - /* 123 */ R0, SN4(tcr, ppc_spr_602_tcr), S(ibr), S(esasrr), > - /* 127 */ S(sebr), S(ser), S(sp), S(lt) > -}; > - > -/* Motorola/IBM PowerPC 603 or 603e. */ > -static const struct reg registers_603[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(hid0), S(hid1), S(iabr), R0, > - /* 123 */ R0, S(dmiss), S(dcmp), S(hash1), > - /* 127 */ S(hash2), S(imiss), S(icmp), S(rpa) > -}; > - > -/* Motorola PowerPC 604 or 604e. */ > -static const struct reg registers_604[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(hid0), S(hid1), S(iabr), S(dabr), > - /* 123 */ S(pir), S(mmcr0), S(pmc1), S(pmc2), > - /* 127 */ S(sia), S(sda) > -}; > - > -/* Motorola/IBM PowerPC 750 or 740. */ > -static const struct reg registers_750[] = > -{ > - COMMON_UISA_REGS, > - PPC_UISA_SPRS, > - PPC_SEGMENT_REGS, > - PPC_OEA_SPRS, > - /* 119 */ S(hid0), S(hid1), S(iabr), S(dabr), > - /* 123 */ R0, S(ummcr0), S(upmc1), S(upmc2), > - /* 127 */ S(usia), S(ummcr1), S(upmc3), S(upmc4), > - /* 131 */ S(mmcr0), S(pmc1), S(pmc2), S(sia), > - /* 135 */ S(mmcr1), S(pmc3), S(pmc4), S(l2cr), > - /* 139 */ S(ictc), S(thrm1), S(thrm2), S(thrm3) > -}; I see that the comments above about variants have been removed. Some of them mention different processor models which also fit the register description, and others describe choices made and restrictions with the register descriptions. Is it worthwhile to transport these to the XML files? > {"601", "Motorola PowerPC 601", bfd_arch_powerpc, > - bfd_mach_ppc_601, -1, -1, tot_num_registers (registers_601), > - registers_601}, > + bfd_mach_ppc_601, &tdesc_powerpc_601}, > + /* FIXME */ > {"602", "Motorola PowerPC 602", bfd_arch_powerpc, > - bfd_mach_ppc_602, -1, -1, tot_num_registers (registers_602), > - registers_602}, > + bfd_mach_ppc_602, &tdesc_powerpc_602}, I'd suggest adding a description about what the FIXME above refers to. > @@ -3780,17 +3404,6 @@ rs6000_gdbarch_init (struct gdbarch_info > switch (info.osabi) > { > case GDB_OSABI_LINUX: > - /* FIXME: pgilliam/2005-10-21: Assume all PowerPC 64-bit linux systems > - have altivec registers. If not, ptrace will fail the first time it's > - called to access one and will not be called again. This wart will > - be removed when Daniel Jacobowitz's proposal for autodetecting target > - registers is implemented. */ > - if ((v->arch == bfd_arch_powerpc) && ((v->mach)== bfd_mach_ppc64)) > - { > - tdep->ppc_vr0_regnum = 71; > - tdep->ppc_vrsave_regnum = 104; > - } The FIXME is being removed above. Was this issue fixed already? It seems it's not, so maybe the FIXME could be moved to somewhere else, like ppc-linux-nat.c where I believe the behaviour comes from? BTW, both powerpc-32.xml and powerpc-64.xml include the altivec feature, so you are assuming that ppc32 has altivec registers as well, right? -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center