This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa:ppc] Convert PPC to "return_value"
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 06 Nov 2003 15:43:45 -0500
- Subject: Re: [rfa:ppc] Convert PPC to "return_value"
- References: <3F946F56.2050409@redhat.com> <1031023161129.ZM13883@localhost.localdomain>
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