Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Michael Snyder <msnyder@redhat.com>, Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com,
	Joel Brobecker <brobecker@gnat.com>,
	jimb@redhat.com
Subject: Re: [RFA] ppc/rs6000: use gdbarch_ps_regnum
Date: Mon, 25 Oct 2004 23:25:00 -0000	[thread overview]
Message-ID: <417D8B02.3060907@gnu.org> (raw)
In-Reply-To: <004401c4b551$8c4691b0$5ca56b80@msnyder8600>

Michael Snyder wrote:
> 
>> On Fri, 15 Oct 2004 17:41:10 -0700
>> Michael Snyder <msnyder@redhat.com> wrote:
>>
>>> I just happened to notice this.  Gdbarch implements PS_REGNUM,
>>> so there's no reason to keep it privately in the tdep struct.
>>
>>
>> Is there some good reason to move it out of the private tdep
>> struct and into the public eye?
>>
>> I'll note that ppc_fp0_regnum is also in the tdep struct, and
>> something comparable (FP0_REGNUM) is also in the gdbarch name space.
>> Yet, rs6000-tdep does not set FP0_REGNUM via set_gdbarch_fp0_regnum()
>> and I happen to like it this way.  The reason is that there's no good
>> reason (that I know of) for the other parts of GDB to be aware of this
>> register numbering.  Also, putting the indexes into the tdep struct
>> gives a uniform mechanism of accessing (most of) the PPC related
>> register numbers.  If we were to move either the PS or FP0 register
>> number back out to gdbarch, then we'd be accessing some of the
>> registers via one mechanism and these others via another.
>> (Unfortunately, we still have SP_REGNUM and PC_REGNUM in gdbarch land.
>> But there are good reasons for other, non-ppc specific portions to
>> know about these register numbers.)

Kevin's correct, and just like DEPRECATED_FP_REGNUM, SP_REGNUM, 
PC_REGNUM, and FP0_REGNUM are all on my hit list :-)

Andrew

> No special reason -- I just figured that if there was a public interface,
> there might be some motivation to use that instead of a private interface.
> 
> PS_REGNUM is referred to quite a lot -- but mostly in other tdep and nat
> files that are orthogonal to this one.  The major exception being 
> std-regs.c,
> which sort-of groups PS in there with PC, SP and (cover your ears, Andrew)
> FP.
> 
> I have no attachment to it, though, if you prefer it the way it is.
> 
> 


      reply	other threads:[~2004-10-25 23:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-16  0:41 Michael Snyder
2004-10-16  1:08 ` Joel Brobecker
2004-10-16  3:23   ` Joel Brobecker
2004-10-16  6:18 ` Kevin Buettner
2004-10-18 20:32   ` Michael Snyder
2004-10-25 23:25     ` Andrew Cagney [this message]

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=417D8B02.3060907@gnu.org \
    --to=cagney@gnu.org \
    --cc=brobecker@gnat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    --cc=kevinb@redhat.com \
    --cc=msnyder@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