From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21220 invoked by alias); 7 Nov 2003 17:12:47 -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 21212 invoked from network); 7 Nov 2003 17:12:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Nov 2003 17:12:46 -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 hA7HCjM12683 for ; Fri, 7 Nov 2003 12:12:45 -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 hA7HCj602989 for ; Fri, 7 Nov 2003 12:12:45 -0500 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id hA7HCiH8001706; Fri, 7 Nov 2003 12:12:44 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id hA7HCdA17796; Fri, 7 Nov 2003 10:12:39 -0700 Date: Fri, 07 Nov 2003 17:12:00 -0000 From: Kevin Buettner Message-Id: <1031107171238.ZM17795@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfa:ppc] Convert PPC to "return_value"" (Nov 6, 3:43pm) References: <3F946F56.2050409@redhat.com> <1031023161129.ZM13883@localhost.localdomain> <3FAAB281.3080702@redhat.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [rfa:ppc] Convert PPC to "return_value" Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00119.txt.bz2 On Nov 6, 3:43pm, Andrew Cagney wrote: > 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; Yes, I had seen both of these. As an implementation technique, I happen to like this structure because it does place the code for the predicate, extract, and store methods in close proximity to each other. However, I remain unconvinced that this is a good "global" interface. While it's true that you've replaced three methods with one, the number of parameters to this one method has increased and the specification of this interface has gotten correspondingly more complex. There's something to be said for simple interfaces. I would've preferred to retain the old interface for global interactions and use your new mechanism as an implementation technique. [...] > 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. Yes, I saw it. Kevin