From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10326 invoked by alias); 9 Dec 2001 21:59:24 -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 10301 invoked from network); 9 Dec 2001 21:59:22 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sources.redhat.com with SMTP; 9 Dec 2001 21:59:22 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 5229A3E2B; Sun, 9 Dec 2001 13:20:47 -0800 (PST) Message-ID: <3C13D5AF.3020700@cygnus.com> Date: Sun, 09 Dec 2001 13:59:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.6) Gecko/20011207 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Regcache changes broke MIPS References: <20011208234027.A12988@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00105.txt.bz2 > mips_register_raw_size (int reg_nr) > 420 { > 421 if (mips64_transfers_32bit_regs_p) > 422 return REGISTER_VIRTUAL_SIZE (reg_nr); > 423 else if (reg_nr >= FP0_REGNUM && reg_nr < FP0_REGNUM + 32 > 424 && FP_REGISTER_DOUBLE) > 425 /* For MIPS_ABI_N32 (for example) we need 8 byte floating point > 426 registers. */ > 427 return 8; > 428 else > > > I assume that this is because the target has not been initialized yet: > #if GDB_MULTI_ARCH > #undef FP_REGISTER_DOUBLE > #define FP_REGISTER_DOUBLE (gdbarch_tdep (current_gdbarch)->mips_fp_register_double) > #endif > > You can't use multi-arched macros from _initialize_regcache, I think. 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. enjoy, Andrew