From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11457 invoked by alias); 16 Feb 2004 19:47:37 -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 11448 invoked from network); 16 Feb 2004 19:47:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Feb 2004 19:47:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AsoiJ-0002T2-9J; Mon, 16 Feb 2004 14:47:31 -0500 Date: Mon, 16 Feb 2004 19:47:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: kettenis@chello.nl, gdb-patches@gcc.gnu.org, cagney@gnu.org Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks Message-ID: <20040216194731.GC1819@nevyn.them.org> Mail-Followup-To: Ulrich Weigand , kettenis@chello.nl, gdb-patches@gcc.gnu.org, cagney@gnu.org References: <20040216015627.GA15870@nevyn.them.org> <200402161301.OAA17984@faui1d.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402161301.OAA17984@faui1d.informatik.uni-erlangen.de> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00426.txt.bz2 On Mon, Feb 16, 2004 at 02:01:29PM +0100, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > > On Mon, Feb 16, 2004 at 02:27:24AM +0100, Ulrich Weigand wrote: > > > +void > > > +dwarf2_frame_set_init_reg (struct gdbarch *gdbarch, > > > + void (*init_reg) (struct gdbarch *, int, > > > + struct dwarf2_frame_state_reg *)) > > > > > Unfortunately this now crashes on s390, because the > > > dwarf2_frame_init routine is called from within > > > _initialize_dwarf2_frame, while the s390 backend calls > > > dwarf2_frame_set_init_reg from within _initialize_s390_tdep. > > > > Er, how? You shouldn't have a gdbarch in _initialize_s390_tdep. You > > don't have one until s390_gdbarch_init. > > 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: > > 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