[RFA] ppc/rs6000: use gdbarch_ps_regnum
Mon Oct 25 23:25:00 GMT 2004
Michael Snyder wrote:
>> On Fri, 15 Oct 2004 17:41:10 -0700
>> Michael Snyder <firstname.lastname@example.org> 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 :-)
> 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
> which sort-of groups PS in there with PC, SP and (cover your ears, Andrew)
> I have no attachment to it, though, if you prefer it the way it is.
More information about the Gdb-patches