From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9598 invoked by alias); 15 Feb 2004 16:04:29 -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 9591 invoked from network); 15 Feb 2004 16:04:27 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 15 Feb 2004 16:04:27 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9714E2B97; Sun, 15 Feb 2004 11:04:26 -0500 (EST) Message-ID: <402F988A.1080508@gnu.org> Date: Sun, 15 Feb 2004 16:04: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: Mark Kettenis Cc: drow@mvista.com, 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00378.txt.bz2 > Date: Sat, 07 Feb 2004 18:48:47 -0500 > From: Andrew Cagney > > > 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. > > Yes. Technical nit though - I think it is still better to have a local > data struct and store the value in there. > > I'm not sure what your idea is here. Is it that you want me to use a > data structure that would be allocated by the dwarf2-frame.c module > such that I'd only need a single per-arch data key for the entire > dwarf2-frame.c module? Yes, just this: > static struct gdbarch_data *frame_base_data; > > struct frame_base_table > { > frame_base_sniffer_ftype **sniffer; .... > }; > > static struct frame_base_table * > frame_base_table (struct gdbarch *gdbarch) > { > struct frame_base_table *table = gdbarch_data (gdbarch, frame_base_data); > ... > return table; > } i.e, put the function inside a struct, instead of storing the function directly in that per-arch data pointer. It's more consistent with: http://sources.redhat.com/gdb/current/onlinedocs/gdbint_13.html#SEC114 but hmm, that's out of date, sigh. Instead of free, memory is obtained using gdbarch_obstack_zalloc. > Or do you want the architecture to allocate > and initialize the structure? The latter would mean more work for the > architecture; if you want to override a single member of the structure > you'd have to fill in all the details. I don't really like that. > > From: Daniel Jacobowitz > Date: Sat, 7 Feb 2004 18:03:30 -0500 > > 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. > > > What about Daniels objections that I'm hand-coding much what > gdbarch.sh already does? I'm feeling that the modularity is worth it, > but how do you feel about that? No. Yes. Using gdbarch, and loosing that modularity, is far too high a price to pay. Andrew