From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21321 invoked by alias); 10 Mar 2003 15:11:21 -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 21313 invoked from network); 10 Mar 2003 15:11:19 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by 172.16.49.205 with SMTP; 10 Mar 2003 15:11:19 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D89102A9C; Mon, 10 Mar 2003 10:11:18 -0500 (EST) Message-ID: <3E6CAB16.10607@redhat.com> Date: Mon, 10 Mar 2003 15:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Add e500 function call support to PPC References: <3E6A4068.9000506@redhat.com> <1030309005725.ZM21224@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00215.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. Such as: if (..... && tdep->ppc_fp0_regnum >= 0) ? Andrew