From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27637 invoked by alias); 15 Feb 2004 20:37:38 -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 27629 invoked from network); 15 Feb 2004 20:37:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Feb 2004 20:37:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AsT1D-0000EG-PK; Sun, 15 Feb 2004 15:37:35 -0500 Date: Sun, 15 Feb 2004 20:37:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks Message-ID: <20040215203735.GA744@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com References: <200402072237.i17Mbqae011375@elgar.kettenis.dyndns.org> <4025795F.9080308@gnu.org> <200402151530.i1FFUaht009031@elgar.kettenis.dyndns.org> <402F988A.1080508@gnu.org> <20040215180922.GA30368@nevyn.them.org> <402FCD3C.3040900@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402FCD3C.3040900@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00383.txt.bz2 On Sun, Feb 15, 2004 at 02:49:16PM -0500, Andrew Cagney wrote: > > > >Since I am obviously not getting it, could someone explain to me what > >the modularity advantage is? > > Are you asking why modularity, in general, is advantage, or why here > specifically this is more modula and hence an advantage? The latter, of course. With a nod towards the former, see below. > The dwarf2-frame is able to locally, and opaquely (to other components) > implement the per-architecture mechanisms that it needs. No need to > bloat that architecture vector with yet another global interface that > nothing, other than dwarf2-frame requires. No need to publish anything > other than what is specificly relevant to dwarf2-frame's clients - the > dwarf2 initialize routine. This is what I don't understand. Almost every architecture supported by GDB will eventually support dwarf2-frame. It is to the architecture's advantage to supply this method, and in fact my understanding was that many architectures will want to use it to indicate which registers are considered call-clobbered and thus no longer available (barring the issue of optimizations which change calling convention). It's no more a marginal method than (to pick an example at random) PC_IN_SIGTRAMP. Why is this different? Are you saying that it would be preferable for many of the methods currently in the architecture vector to move outside of it into more modular pieces, e.g. function calling, type-related, et cetera? When you have that many pieces, I'm not sure that you've gained any clarity. So the architecture initialization functions will change into a lot of set_dwarf2_frame_foo_func, set_infcall_bar_func instead of set_gdbarch_foo_func and set_infcall_bar_func. > > >All I see is a function pointer, with a default value or overridden by > >the architecture initialization, used to parametrize a module's > >behavior. That is the same niche as every existing member of the > >gdbarch vector. > > Andrew > > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer