[rfa:ppc] Convert PPC to "return_value"

[Kevin Buettner]

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