From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25842 invoked by alias); 6 Nov 2003 20:43:50 -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 25820 invoked from network); 6 Nov 2003 20:43:49 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 6 Nov 2003 20:43:49 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2B0D22B8F; Thu, 6 Nov 2003 15:43:45 -0500 (EST) Message-ID: <3FAAB281.3080702@redhat.com> Date: Thu, 06 Nov 2003 20:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa:ppc] Convert PPC to "return_value" References: <3F946F56.2050409@redhat.com> <1031023161129.ZM13883@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00101.txt.bz2 Ping. > On Oct 20, 7:27pm, Andrew Cagney wrote: > > >> The attached switches the PPC architectures over to the new >> "return_value" gdbarch method. > I'm still thinking about this one. > > The problem that I have with this patch is that I'm not convinced that > it's always desirable to combine the "use struct convention" code > with the code which implements the loading/storing of the return > value. From the doco: : @emph{Maintainer note: This method replaces separate predicate, extract, : store methods. By having only one method, the logic needed to determine : the return-value convention need only be implemented in one place. If : @value{GDBN} were written in an @sc{oo} language, this method would : instead return an object that knew how to perform the register : return-value extract and store.} and my earlier comment: : Also, for the case you describe, it could easily written as: : : if (value in register) : if (inval) : extract_return_value () : if (outval) : store_return_value () : return RETURN_VALUE_REGISTER_CONVENTION; : else : return RETURN_VALUE_STRUCT_CONVENTION; > Due to the way the PPC ABIs are specified, I do happen to like this > approach for PPC. However, I'm not convinced that this is the best > approach for all architectures. > > So I'm still mulling it over... Did you see this? : Due to a lack of coverage in the testsuite, this change : doesn't actually improve the existing test results (ppc64 : GNU/Linux and ppc32 NetBSD). : Consequently, I wrote some new tests (will post in next few : days) that beef up the testsuite and, with them, the results : definitly improve! It was lost from your reply. Andrew