From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8811 invoked by alias); 10 Mar 2003 17:54:13 -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 8777 invoked from network); 10 Mar 2003 17:54:12 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 10 Mar 2003 17:54:12 -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 h2AHsCQ08803 for ; Mon, 10 Mar 2003 12:54:12 -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 h2AHsAV06905; Mon, 10 Mar 2003 12:54:10 -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 h2AHsA113073; Mon, 10 Mar 2003 12:54:10 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2AHs4x03627; Mon, 10 Mar 2003 10:54:04 -0700 Date: Mon, 10 Mar 2003 17:54:00 -0000 From: Kevin Buettner Message-Id: <1030310175404.ZM3626@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfa] Add e500 function call support to PPC" (Mar 10, 10:11am) References: <3E6A4068.9000506@redhat.com> <1030309005725.ZM21224@localhost.localdomain> <3E6CAB16.10607@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/msg00219.txt.bz2 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. Kevin