From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16732 invoked by alias); 6 Oct 2003 15:52:15 -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 16721 invoked from network); 6 Oct 2003 15:52:12 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 6 Oct 2003 15:52:12 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0CEE62B89; Mon, 6 Oct 2003 11:52:11 -0400 (EDT) Message-ID: <3F818FAA.6050005@redhat.com> Date: Mon, 06 Oct 2003 15:52: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: Corinna Vinschen Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c (sh_use_struct_convention): Restructure and fix References: <20031004113939.GK11435@cygbert.vinschen.de> <3F7EED21.1060902@redhat.com> <20031004180852.GA29063@cygbert.vinschen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00103.txt.bz2 > On Sat, Oct 04, 2003 at 11:54:09AM -0400, Andrew Cagney wrote: > >> > * sh-tdep.c (sh_use_struct_convention): Clean up to have a >> > more readable code. Accomodate 4 byte structs with 4 byte sized >> > first field (e.g. bitfields). > >> >> Corinna, >> >> See: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00033.html. >> The ppc64_sysv_return_value code in ppc-sysv-tdep.c, has been written in >> a way that allows a quick update to this new iterface. > > > I think my patch is fine. I'm fixing non-deprecated functions to > work better than before. There's nothing wrong with this and I > don't see any gain to use an entirely new technique (2 days old!) > to get probably new errors which I don't have using this method. Corinna, here are some URLs that pretty much spell out the fact that these changes are comming. They are even prompted by problems you, yourself, identifed. 2003-09-29: [wip] return value architecture method http://sources.redhat.com/ml/gdb-patches/2003-09/msg00616.html which was me giving a very clear heads up that the method was comming. 2003-09-28: value to function? http://sources.redhat.com/ml/gdb/2003-09/msg00345.html 2003-09-20: [rfa:ppc64] Fix return value http://sources.redhat.com/ml/gdb-patches/2003-09/msg00435.html For the origin of that version. 2003-08-??: [rfc] Supporting alternative ABIs http://sources.redhat.com/ml/gdb/2003-08/msg00252.html For for a potential future need to add "struct value *function". 2003-09-30: Phone discussion where I alerted you to these pending changes. > Fixing the bugs is step 1. Converting them to a new technique is > another, later step. It stops the existing test cases failing. Unfortunatly the testsuite is deficient in this area, lacking proper coverage of this feature (would you like to help me improve the testsuite?). Unless the new _return_value method is used, GDB refuses to handle: (gdb) list struct { float f; } s; (gdb) return s; In fact, your SH changes to store_return_value: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00077.html that try to handle this specific case are never executed! See set_return_value. So? There's a judgment call here - will GDB be better off using the old or new technique during this transition period? Here, I think it is questionably the case that it is in everyones best interest to make the switch. This is because things will be in a much better position for the change to add a "struct value *function" method to the return-value code (I assume that that you're still working towards that). The old code would have required mods to four architecture methods (RETURN_VALUE_ON_STACK was missed) while the new code will involve mods to only one. I should also note that what I'm suggesting here isn't exactly rocket science. Just grab extract_return_value, or store_return_value, and massage it into return_value. I just did it for ppc32 and it took an hour, at max in the case of ppc64 it was a day. Andrew