From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20875 invoked by alias); 7 Feb 2004 23:03:32 -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 20864 invoked from network); 7 Feb 2004 23:03:30 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Feb 2004 23:03:30 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1ApbU2-0001lh-BH for ; Sat, 07 Feb 2004 18:03:30 -0500 Date: Sat, 07 Feb 2004 23:03:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks Message-ID: <20040207230330.GA6717@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200402072237.i17Mbqae011375@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402072237.i17Mbqae011375@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00155.txt.bz2 On Sat, Feb 07, 2004 at 11:37:52PM +0100, Mark Kettenis wrote: > Here's my proposal for the per-architecture DWARF CFI register state > initialization hooks needed for S/390, and others. This is a RFC, > since I'm not entirely confident whether my approach is acceptable. I > chose to implement this using per-architecture data instead of adding > a function to the architecture vector. I think it is cleaner since it > keeps things localized and modular, and the architecture vector is big > enough as it stands. However you folks might think otherwise. Hmm, I do. You're adding a per-architecture data item which is a function pointer, and what amounts to the rest of what gdbarch.sh would generate (wrapper functions, default initialization. I'd rather you just used gdbarch.sh. > Ulrich, this should privide the hooks you need. For S/390 you should > provide a function with the following signature: > > void > s390_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum, > struct gdbarch dwarf2_frame_state_reg *reg); > > and initialize REG according to your needs for the REGNUMs you care > about. Note that REGNUM is the GDB register number. > > Comments? I've no objection. I would have done something like: void gdbarch_dwarf2_frame_init_reg (struct gdbarch *gdbarch, struct dwarf3_frame_state_reg *reg); dwarf2_frame_default_init_reg (reg); gdbarch_dwarf2_frame_init_reg (gdbarch, reg); but this is just as good, and we're not _that_ pinched for startup time. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer