From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24212 invoked by alias); 15 Feb 2004 15:31:08 -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 24193 invoked from network); 15 Feb 2004 15:31:03 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 15 Feb 2004 15:31:03 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1FFUghH000373; Sun, 15 Feb 2004 16:30:42 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1FFUfdl009034; Sun, 15 Feb 2004 16:30:41 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i1FFUaht009031; Sun, 15 Feb 2004 16:30:36 +0100 (CET) Date: Sun, 15 Feb 2004 15:31:00 -0000 Message-Id: <200402151530.i1FFUaht009031@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org, drow@mvista.com CC: gdb-patches@sources.redhat.com In-reply-to: <4025795F.9080308@gnu.org> (message from Andrew Cagney on Sat, 07 Feb 2004 18:48:47 -0500) Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks References: <200402072237.i17Mbqae011375@elgar.kettenis.dyndns.org> <4025795F.9080308@gnu.org> X-SW-Source: 2004-02/txt/msg00376.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? 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? Mark