From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10422 invoked by alias); 25 Oct 2004 23:25:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10411 invoked from network); 25 Oct 2004 23:25:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 25 Oct 2004 23:25:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id i9PNP0hT022269 for ; Mon, 25 Oct 2004 19:25:07 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9PNOxr11899; Mon, 25 Oct 2004 19:25:00 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 247381294B5; Mon, 25 Oct 2004 19:23:49 -0400 (EDT) Message-ID: <417D8B02.3060907@gnu.org> Date: Mon, 25 Oct 2004 23:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Michael Snyder , Kevin Buettner Cc: gdb-patches@sources.redhat.com, Joel Brobecker , jimb@redhat.com Subject: Re: [RFA] ppc/rs6000: use gdbarch_ps_regnum References: <41706E26.3050804@redhat.com> <20041015231816.075969be@saguaro> <004401c4b551$8c4691b0$5ca56b80@msnyder8600> In-Reply-To: <004401c4b551$8c4691b0$5ca56b80@msnyder8600> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00425.txt.bz2 Michael Snyder wrote: > >> On Fri, 15 Oct 2004 17:41:10 -0700 >> Michael Snyder 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. > >