Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Richard Henderson <rth@redhat.com>, Jim Blandy <jimb@redhat.com>
Cc: Kevin Buettner <kevinb@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method
Date: Fri, 13 Jun 2003 06:17:00 -0000	[thread overview]
Message-ID: <1030613061734.ZM459@localhost.localdomain> (raw)
In-Reply-To: Richard Henderson <rth@redhat.com> "Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method" (Jun 12,  9:48pm)

On Jun 12,  9:48pm, Richard Henderson wrote:

> On Thu, Jun 12, 2003 at 04:11:31PM -0500, Jim Blandy wrote:
> > + /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 Linux.
> 
> Not just Linux, but everywhere else as well.
> 
> Indeed, the 64-bit ABI lifts this from 32-bit AIX, so it seems
> like this function should be generic in the ppc backend somewhere.

It does exist in rs6000-tdep.c (as rs6000_convert_from_func_ptr_addr)
and I believe that that function would work for 64-bit PPC Linux also.

So, an alternate approach (to what Jim did) is to export
rs6000_convert_from_func_ptr_addr() via ppc-tdep.h and then register
it in ppc-linux-tdep.c.  That may be preferable in this case since
this function is relatively simple and it could be argued that if
there is a bug in the code, it would likely be a bug for both ABIs. 
Fixing such a bug in one location is preferable to having to fix it in
multiple locations.

OTOH, there's been a recent trend towards separating this kind of
thing out for different ABIs.  E.g, look at all of push_argument
variants in mips-tdep.c.  At one time, not too long ago, all of
the push_argument() variants were rolled into one big function.
(There are some other MIPS related examples that are somewhat
less extreme.)  The reason that this was done is so that fixes
may be made to the support of a given ABI without having to worry
about breaking the support for the other ABIs.

There are pros and cons to each approach and, for this case, I don't
see a clear cut winner.  Since Jim is in the code at the moment, and
has been giving it a lot of thought, I'll leave it up to him to decide
on the best course of action.

Kevin


  reply	other threads:[~2003-06-13  6:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-11  8:52 Jim Blandy
2003-06-11 22:42 ` Kevin Buettner
2003-06-12 21:11   ` Jim Blandy
2003-06-12 21:44     ` Kevin Buettner
2003-06-13  4:48     ` Richard Henderson
2003-06-13  6:17       ` Kevin Buettner [this message]
2003-06-13 22:54         ` 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=1030613061734.ZM459@localhost.localdomain \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    --cc=rth@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