From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16351 invoked by alias); 15 Feb 2004 21:37:10 -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 16336 invoked from network); 15 Feb 2004 21:37:08 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 15 Feb 2004 21:37:08 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 848522B97; Sun, 15 Feb 2004 16:36:50 -0500 (EST) Message-ID: <402FE672.5080506@gnu.org> Date: Sun, 15 Feb 2004 21:37:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks 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> <20040215203735.GA744@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00385.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). But why should the architecture be supplying it to gdbarch, when it is the dwarf2 frame code that needs it? > It's no more a marginal method than (to pick an > example at random) PC_IN_SIGTRAMP. Er: Use get_frame_type() == SIGTRAMP_FRAME instead of PC_IN_SIGTRAMP http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1159 > 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. Um, actually, why is this case different? Neither Mark nor I are doing anything new here. frame-unwind, libunwind-frame, user-regs, frame-base, reggroups, regcache, v3abi, ... all, already use gdbarch_data. The general trend of decomposing gdbarch into more digestable chunks has been going on for years. While existing code continues to add to gdbarch.sh, new more modular code is using gdbarch_data. > 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. MarkK is equally free to do something like replace frame-unwind::add_frame_sniffer (gdbarch, dwarf2-frame::dwarf2_frame_sniffer); with: dwarf2-frame::add_dwarf2_frame_sniffer (gdbarch, ); In fact, Mark, I'd highly recommend it - it will screw down the interface further. enjoy, Andrew