From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21143 invoked by alias); 15 Feb 2004 22:54:40 -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 21134 invoked from network); 15 Feb 2004 22:54:38 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Feb 2004 22:54:38 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AsV9i-0000v0-4R; Sun, 15 Feb 2004 17:54:30 -0500 Date: Sun, 15 Feb 2004 22:54: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: <20040215225429.GA3264@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> <20040215203735.GA744@nevyn.them.org> <402FE672.5080506@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402FE672.5080506@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00389.txt.bz2 On Sun, Feb 15, 2004 at 04:36:50PM -0500, Andrew Cagney wrote: > But why should the architecture be supplying it to gdbarch, when it is > the dwarf2 frame code that needs it? By this explanation nothing belongs in gdbarch at all. Gdbarch is not a thing which can need other things. It has producers and consumers but is neither. It sounds like we're moving away from gdbarch as the repository of target-specific code in favor of each subsystem parametrizing itself. Is that a good summary? > 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. Some of those at least are not good examples, because they are either orthogonal to the OS/ABI - c++ ABI (v3abi) - or not one-to-one with the ABI (frame unwind, frame base). Whereas this method describes a property of the ABI. That's how it's different. > While existing code continues to add to gdbarch.sh, new more modular > code is using gdbarch_data. I guess the above is a good summary, then. Should it be written down somewhere? I find the step from module-specific per-architecture data (created by the module) to module-specific per-architecture configuration hooks (provided, maybe optionally, by the architecture) to be a bit confusing. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer