From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27439 invoked by alias); 4 Apr 2002 16:42:14 -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 27426 invoked from network); 4 Apr 2002 16:42:12 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 4 Apr 2002 16:42:12 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16tAJU-0008Hs-00; Thu, 04 Apr 2002 11:42:16 -0500 Date: Thu, 04 Apr 2002 08:42:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: hunt@redhat.com, gdb@sources.redhat.com, cagney@redhat.com Subject: Re: Alpha completely broken: build_regcache never called Message-ID: <20020404114216.A31713@nevyn.them.org> Mail-Followup-To: Andrew Cagney , hunt@redhat.com, gdb@sources.redhat.com, cagney@redhat.com References: <20020403180530.A570@nevyn.them.org> <3CABE158.5080706@cygnus.com> <20020404002511.A11444@nevyn.them.org> <3CAC61E0.7040300@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CAC61E0.7040300@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00054.txt.bz2 On Thu, Apr 04, 2002 at 09:23:28AM -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())? Yep. Want me to check it in? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer