From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31877 invoked by alias); 7 Oct 2003 14:52:16 -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 31869 invoked from network); 7 Oct 2003 14:52:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Oct 2003 14:52:14 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h97EqC128718 for ; Tue, 7 Oct 2003 10:52:13 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h97EqBD14761 for ; Tue, 7 Oct 2003 10:52:12 -0400 Received: from cygbert.vinschen.de (vpn50-11.rdu.redhat.com [172.16.50.11]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h97Eq9w16131 for ; Tue, 7 Oct 2003 07:52:09 -0700 Received: by cygbert.vinschen.de (Postfix, from userid 500) id 861CA58044; Tue, 7 Oct 2003 16:52:05 +0200 (CEST) Date: Tue, 07 Oct 2003 14:52:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-tdep.c (sh_use_struct_convention): Restructure and fix Message-ID: <20031007145205.GA10834@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031004113939.GK11435@cygbert.vinschen.de> <3F7EED21.1060902@redhat.com> <20031004180852.GA29063@cygbert.vinschen.de> <3F818FAA.6050005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F818FAA.6050005@redhat.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-10/txt/msg00165.txt.bz2 Andrew, On Mon, Oct 06, 2003 at 11:52:10AM -0400, Andrew Cagney wrote: > >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, 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. so the premonition time was a whole week. I'm impressed. I'm sorry that I missed this due to being busy enough to concentrate on my target. > 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. Again sorry, I don't read postings about targets I have no relation to. > 2003-09-30: Phone discussion where I alerted you to these pending changes. I don't think that this belongs to gdb-patches. > 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. Which is arguably a bug in set_return_value(), not in my code. > 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 don't think so since from my point of view your new functionality has some interesting flaws or, at least, points which have to be discussed first. See my other posting replying to your wip posting. Really, holding off a good working patch because another not yet discussed functionality is glancing over the horizon for just 8 days isn't quite useful, IMHO. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc.