Re: [RFA] sh-tdep.c (sh_use_struct_convention): Restructure and fix

[Corinna Vinschen <vinschen@redhat.com>]

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.