From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27590 invoked by alias); 4 Apr 2002 14:23:31 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27567 invoked from network); 4 Apr 2002 14:23:27 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 4 Apr 2002 14:23:27 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 43B883E59; Thu, 4 Apr 2002 09:23:28 -0500 (EST) Message-ID: <3CAC61E0.7040300@cygnus.com> Date: Thu, 04 Apr 2002 06:23:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , hunt@redhat.com Cc: gdb@sources.redhat.com, cagney@redhat.com Subject: Re: Alpha completely broken: build_regcache never called References: <20020403180530.A570@nevyn.them.org> <3CABE158.5080706@cygnus.com> <20020404002511.A11444@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00042.txt.bz2 > On Thu, Apr 04, 2002 at 12:15:04AM -0500, Andrew Cagney wrote: > >> >I believe this patch is responsible: >> > >> >2002-03-20 Martin M. Hunt >> > >> >* regcache.c (_initialize_regcache): No need to call >> > build_regcache() at this time; it gets called whenever >> > the gdbarch changes. >> > >> >Alpha is completely non-multi-arch. Thus the gdbarch appears to never >> >change, and we crash very quickly. > >> >> When non-multi-arch, that function should still be called via: >> >> initialize_non_multiarch (); >> >> is this not happening? > > > That function only initializes things created with > register_gdbarch_data... not register_gdbarch_swap. Adding a call to > init_gdbarch_swap (&startup_gdbarch) in initialize_non_multiarch causes > it to be called. Is that correct? Er, yes :-( Does it ``work'' (between the other two functions to match gdbarch_update_p())? There could be a problem (memory leak, NULL test?) if code is doing the sequence: _initialize_foo() -> build_foo() .... _initialize_non_multiarch() -> init_gdbarch_swap() -> build_foo () but I think I can live with that (with liberal commenting :-) as it is the non-multi-arch case. This looks to also be a partial fix to gdb/438. The underlying problem is still there but this further improves things. Andrew