Re: [rfa:ppc] Convert PPC to "return_value"

[Andrew Cagney <ac131313@redhat.com>]

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;

> Due to the way the PPC ABIs are specified, I do happen to like this
> approach for PPC.  However, I'm not convinced that this is the best
> approach for all architectures.
> 
> So I'm still mulling it over...

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.

Andrew