From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4726 invoked by alias); 10 Mar 2003 21:47:00 -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 4715 invoked from network); 10 Mar 2003 21:46:59 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 10 Mar 2003 21:46:59 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h2ALkxQ06340 for ; Mon, 10 Mar 2003 16:46:59 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h2ALkvV05685; Mon, 10 Mar 2003 16:46:57 -0500 Received: from localhost.localdomain (vpn50-43.rdu.redhat.com [172.16.50.43]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h2ALku106553; Mon, 10 Mar 2003 16:46:56 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2ALkpZ04444; Mon, 10 Mar 2003 14:46:51 -0700 Date: Mon, 10 Mar 2003 21:47:00 -0000 From: Kevin Buettner Message-Id: <1030310214650.ZM4443@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfa] Add e500 function call support to PPC" (Mar 10, 2:56pm) References: <3E6A4068.9000506@redhat.com> <1030309005725.ZM21224@localhost.localdomain> <3E6CAB16.10607@redhat.com> <1030310175404.ZM3626@localhost.localdomain> <3E6CEE02.10005@redhat.com> To: Andrew Cagney Subject: Re: [rfa] Add e500 function call support to PPC Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00238.txt.bz2 On Mar 10, 2:56pm, Andrew Cagney wrote: > > On Mar 10, 10:11am, Andrew Cagney wrote: > > > >> > This construct bothers me. If it occurred only once, it might not > >> > bother me so much, but (arch_info->mach != bfd_mach_ppc_e500) appears > >> > far too often in the code for me to be comfortable with it. Suppose > >> > we have another core with a similar property (of passing everything > >> > in GPRs). If this happens, we'll end up with a proliferation of > >> > additional checks for all of these different cores and things will > >> > become quite unreadable. Please introduce a predicate into which > >> > we can put this test and perhaps others as they arise. Then, only > >> > the predicate will need to be modified. > > > >> > >> Such as: > >> > >> if (..... > >> && tdep->ppc_fp0_regnum >= 0) > >> > >> ? > > > > If the ppc's tdep struct had such a member that would probably be okay. > > It currently doesn't. However, it occured to me that it should be added > anyway. There is nothing indicating to the shared PPC code that the > e500 doesn't have FPRs. For the time being, how about introducing a predicate (function) to ppc-sysv-tdep.c (or perhaps rs6000-tdep.c) named have_floating_point_registers_p() (or something along those lines). In the short term this could be defined as: int have_floating_point_registers_p (struct gdbarch *gdbarch) { const struct bfd_arch_info *arch_info = gdbarch_bfd_arch_info (gdbarch); /* Note: It has been proposed that a ``ppc_fp0_regnum'' member be added to the ppc tdep struct. If/when this occurs, it may be preferable to implement this as: struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); return tdep->ppc_fp0_regnum >= 0; */ return arch_info->mach != bfd_mach_ppc_e500; } It occurs to me that such a predicate would be useful for checking the state of a global variable in the event that a command similar to ``set nomipsfpu'' were added for the powerpc. (Well, maybe. Then again, maybe it'd be better to just set ppc_fp0_regnum to -1 when such a setting were made.) In any event, a name like have_floating_point_registers_p() is reasonably self docuementing whereas ``tdep->ppc_fp0_regnum >= 0'' requires a little bit more thought to discern the meaning. Kevin