From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14291 invoked by alias); 9 Mar 2003 01:00:14 -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 14281 invoked from network); 9 Mar 2003 01:00:13 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 9 Mar 2003 01:00:13 -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 h290vXQ30739 for ; Sat, 8 Mar 2003 19:57:33 -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 h290vWV12903; Sat, 8 Mar 2003 19:57:32 -0500 Received: from localhost.localdomain (vpn50-19.rdu.redhat.com [172.16.50.19]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h290vV101271; Sat, 8 Mar 2003 19:57:31 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h290vQ721225; Sat, 8 Mar 2003 17:57:26 -0700 Date: Sun, 09 Mar 2003 01:00:00 -0000 From: Kevin Buettner Message-Id: <1030309005725.ZM21224@localhost.localdomain> In-Reply-To: Andrew Cagney "[rfa] Add e500 function call support to PPC" (Mar 8, 2:11pm) References: <3E6A4068.9000506@redhat.com> To: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [rfa] Add e500 function call support to PPC MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00198.txt.bz2 On Mar 8, 2:11pm, Andrew Cagney wrote: > This adds support for the e500's function call convention to the PPC > (ppc-sysv-tdep.c to be exact). > > The e500 passes everything in GPRs (which are extended to 64 bits). > [...] > - if (TYPE_CODE (type) == TYPE_CODE_FLT) > + if (TYPE_CODE (type) == TYPE_CODE_FLT > + && arch_info->mach != bfd_mach_ppc_e500) 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. Kevin