From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18000 invoked by alias); 16 Feb 2004 13:01:34 -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 17958 invoked from network); 16 Feb 2004 13:01:32 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 16 Feb 2004 13:01:32 -0000 Received: from faui1d.informatik.uni-erlangen.de (faui1d [131.188.31.34]) by faui10.informatik.uni-erlangen.de (8.9.3p3/8.1.9-FAU) with ESMTP id OAA10886; Mon, 16 Feb 2004 14:01:30 +0100 (CET) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id OAA17984; Mon, 16 Feb 2004 14:01:29 +0100 (CET) Message-Id: <200402161301.OAA17984@faui1d.informatik.uni-erlangen.de> Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks To: drow@false.org (Daniel Jacobowitz) Date: Mon, 16 Feb 2004 13:01:00 -0000 Cc: weigand@i1.informatik.uni-erlangen.de (Ulrich Weigand), kettenis@chello.nl, gdb-patches@gcc.gnu.org, cagney@gnu.org In-Reply-To: <20040216015627.GA15870@nevyn.them.org> from "Daniel Jacobowitz" at Feb 15, 2004 08:56:28 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00397.txt.bz2 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) Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de