From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25734 invoked by alias); 16 Oct 2004 06:18:27 -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 25722 invoked from network); 16 Oct 2004 06:18:26 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 Oct 2004 06:18:26 -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.10) with ESMTP id i9G6IP35010239 for ; Sat, 16 Oct 2004 02:18:25 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9G6INr00677; Sat, 16 Oct 2004 02:18:23 -0400 Received: from localhost.localdomain (vpn50-43.rdu.redhat.com [172.16.50.43]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i9G6IMYo031522; Sat, 16 Oct 2004 02:18:23 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i9G6IHo3014697; Fri, 15 Oct 2004 23:18:17 -0700 Date: Sat, 16 Oct 2004 06:18:00 -0000 From: Kevin Buettner To: Michael Snyder Cc: gdb-patches@sources.redhat.com, Joel Brobecker , jimb@redhat.com Subject: Re: [RFA] ppc/rs6000: use gdbarch_ps_regnum Message-Id: <20041015231816.075969be@saguaro> In-Reply-To: <41706E26.3050804@redhat.com> References: <41706E26.3050804@redhat.com> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00292.txt.bz2 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