From: Kevin Buettner <kevinb@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>, Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa:ppc] Convert PPC to "return_value"
Date: Fri, 07 Nov 2003 17:12:00 -0000 [thread overview]
Message-ID: <1031107171238.ZM17795@localhost.localdomain> (raw)
In-Reply-To: Andrew Cagney <ac131313@redhat.com> "Re: [rfa:ppc] Convert PPC to "return_value"" (Nov 6, 3:43pm)
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
next prev parent reply other threads:[~2003-11-07 17:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-20 23:27 Andrew Cagney
2003-10-23 16:11 ` Kevin Buettner
2003-11-06 20:43 ` Andrew Cagney
2003-11-07 17:12 ` Kevin Buettner [this message]
2003-11-07 16:25 ` Kevin Buettner
2003-11-07 20:45 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1031107171238.ZM17795@localhost.localdomain \
--to=kevinb@redhat.com \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox