From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 339 invoked by alias); 10 Dec 2001 22:34:58 -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 32764 invoked from network); 10 Dec 2001 22:34:43 -0000 Received: from unknown (HELO localhost.cygnus.com) (205.180.231.71) by sources.redhat.com with SMTP; 10 Dec 2001 22:34:43 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 9D64D3D60; Mon, 10 Dec 2001 14:34:35 -0800 (PST) Message-ID: <3C15387B.8010207@cygnus.com> Date: Mon, 10 Dec 2001 14:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.6) Gecko/20011207 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Buettner Cc: Elena Zannoni , Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] ppc: include register numbers in gdbarch_tdep structure. References: <15379.50110.429092.453327@krustylu.cygnus.com> <3C150D60.631D281C@cygnus.com> <1011210202327.ZM32506@ocotillo.lan> <15381.8009.857527.631618@krustylu.cygnus.com> <1011210212045.ZM1405@ocotillo.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00290.txt.bz2 > > Andrew recently said the following: > > On paper, it should be possible to describe the entire raw regcache > using constants. I'm finding that, in reality, until all the relevant > framework is fleshed out (eg my regcache breakage, everything > multi-arch) it isn't really possible. Sigh. > > This suggests to me that someday, though probably not very soon, it > may indeed be possible to use actual constants. As you can probably > tell, I really, really hate the overhead of a function call to provide > the value of something that ought to be a constant. Hmm, something else we're doing is moving away from the assumption that there is a global current_gdbarch. Consequently the macro should be parameterized vis: #define PPC_MQ_REGNUM(ARCH) (gdbarch_tdep ((ARCH))->ppc_mq_regnum) As for other alternatives, I used something like: { const struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); .... ... tdep->ppc_mq_regnum ... .... } in remote.c. Still, I figure this is all small fish compared to the possability of actually fixing GDB's thread and frame code so that more than one instance was available and thus we dramatically cut down on the number of system / remote calls - which are the real killer. BTW, even if GDB did support macro's I'd still argue agains them - call by name semantics for instance. They just sux. enjoy, Andrew