From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10662 invoked by alias); 9 Dec 2001 23:34:32 -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 10558 invoked from network); 9 Dec 2001 23:33:16 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 9 Dec 2001 23:33:16 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16DDRQ-00040n-00; Sun, 09 Dec 2001 18:33:04 -0500 Date: Sun, 09 Dec 2001 15:34:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Regcache changes broke MIPS Message-ID: <20011209183304.A15018@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20011208234027.A12988@nevyn.them.org> <3C13D5AF.3020700@cygnus.com> <3C13EB35.7040100@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C13EB35.7040100@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00108.txt.bz2 On Sun, Dec 09, 2001 at 02:52:37PM -0800, Andrew Cagney wrote: > >Grumph. > > > >Because GDB isn't 100% multi-arch, it ends up having to use target macros > >from within _initialize_*(). Otherwize non- multi-arch code won't start up > >right. When multi-arch is enabled, a dummy multi-arch vector is used. > > > >Anyway, I think there is something even more messed up here. First, I'm > >not sure why that function was called from within an _initialize*() > >function. Secondly, the logic just looks backwards. > > > >I'll do some pokeing. > > > Hmm, doctor the patient is worse than we thought (and how ironic, this > one is my target). > > Briefly, the MIPS still defines certain methods (REGISTER_RAW_SIZE() at > least) as macro's mapped onto functions instead of true multi-arch > methods. That is why they are being called when they shouldn't. > > I came up with a patch that fixed just REGISTER_RAW_SIZE() but that > didn't fix it - suspect I need to find more. I think I follow. Do you actually currently build the register cache with dummy values (on a multiarch target) and then rebuild it after gdbarch is initialized? It seems like there should be a way to register a post-gdbarch, non-multi-arch-target init function to avoid this. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer