From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22985 invoked by alias); 16 Feb 2004 20:50:17 -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 22967 invoked from network); 16 Feb 2004 20:50:15 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 16 Feb 2004 20:50:15 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 58BCA2B92; Mon, 16 Feb 2004 15:50:09 -0500 (EST) Message-ID: <40312D01.3040704@gnu.org> Date: Mon, 16 Feb 2004 20:50: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: Ulrich Weigand , kettenis@chello.nl, gdb-patches@gcc.gnu.org Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks References: <20040216015627.GA15870@nevyn.them.org> <200402161301.OAA17984@faui1d.informatik.uni-erlangen.de> <20040216194731.GC1819@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00428.txt.bz2 >> Sorry, my analysis wasn't completely correct. What actually happens >> is an init-order problem during the initialization of the gdbarch >> in initialize_current_architecture. The problem is that I call >> dwarf2_frame_set_init_reg from within the s390_gdbarch_init routine >> (which I gather is the right place?), and at this point in time, >> the gdbarch_data call in dwarf2_frame_set_init_reg returns NULL >> because the gdbarch hasn't finished initialization yet: I've committed the attatched. It follows the convention described in that revised doco patch I posted: http://sources.redhat.com/ml/gdb-patches/2004-02/msg00381.html Andrew >> gdbarch_data (struct gdbarch *gdbarch, struct gdbarch_data *data) >> { >> gdb_assert (data->index < gdbarch->nr_data); >> /* The data-pointer isn't initialized, call init() to get a value but >> only if the architecture initializaiton has completed. Otherwise >> punt - hope that the caller knows what they are doing. */ >> if (gdbarch->data[data->index] == NULL >> && gdbarch->initialized_p) > > > Oopsie. Yes, now I can see what's going on - I'm not sure what should > change here. Andrew, do you recall if the initialized_p check was for > any specific problem, or might we be able to remove it? > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer