From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2340 invoked by alias); 16 Feb 2004 01:28: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 2331 invoked from network); 16 Feb 2004 01:28:27 -0000 Received: from unknown (HELO faui10.informatik.uni-erlangen.de) (131.188.31.10) by sources.redhat.com with SMTP; 16 Feb 2004 01:28:27 -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 CAA00860; Mon, 16 Feb 2004 02:27:24 +0100 (CET) From: Ulrich Weigand Received: (from weigand@localhost) by faui1d.informatik.uni-erlangen.de (8.9.3p3/8.1.6-FAU) id CAA17805; Mon, 16 Feb 2004 02:27:24 +0100 (CET) Message-Id: <200402160127.CAA17805@faui1d.informatik.uni-erlangen.de> Subject: Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks To: kettenis@chello.nl Date: Mon, 16 Feb 2004 01:28:00 -0000 Cc: gdb-patches@gcc.gnu.org, cagney@gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00393.txt.bz2 Mark Kettenis wrote: +/* Return a default for the architecture-specific operations. */ + +static void * +dwarf2_frame_init (struct gdbarch *gdbarch) +{ + struct dwarf2_frame_ops *ops; + + ops = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct dwarf2_frame_ops); + ops->init_reg = dwarf2_frame_default_init_reg; + return ops; +} + +/* Set the architecture-specific register state initialization + function for GDBARCH to INIT_REG. */ + +void +dwarf2_frame_set_init_reg (struct gdbarch *gdbarch, + void (*init_reg) (struct gdbarch *, int, + struct dwarf2_frame_state_reg *)) +{ + struct dwarf2_frame_ops *ops; + + ops = gdbarch_data (gdbarch, dwarf2_frame_data); + ops->init_reg = init_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. Now, in the generated initialize_all_files routine, the s390_tdep init routine is called *before* the dwarf2_frame one, and hence dwarf2_frame_set_init_reg gets called before dwarf2_frame_init. Thus, the gdbarch_data call returns NULL, and the assignment to ops->init_reg crashes. Is there some usual way to solve this sort of init-order issues with the gdb init sequence? Bye, Ulrich -- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de