From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18850 invoked by alias); 13 Jun 2002 15:14:59 -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 18843 invoked from network); 13 Jun 2002 15:14:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.19.120.103) by sources.redhat.com with SMTP; 13 Jun 2002 15:14:56 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17IWJs-0001Fp-00 for ; Thu, 13 Jun 2002 11:15:28 -0400 Date: Thu, 13 Jun 2002 08:14:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: gdbarch: ABFD no longer available at gdbarch_update_p time Message-ID: <20020613151528.GA4688@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00099.txt.bz2 I'm trying to add a ``set mips abi'' as we discussed earlier. I can't find a way to do it. The way CRIS does this sort of thing is patently wrong (for MIPS at least, if not for CRIS also): /* Update the current architecture, if needed. */ gdbarch_info_init (&info); if (!gdbarch_update_p (info)) internal_error (__FILE__, __LINE__, "cris_gdbarch_update: failed to update architecture."); That builds a new architecture based entirely on the defaults. info.abfd is gone at that point, and that's how MIPS makes lots of its decisions. OSABI support makes this even more pronounced. I'd like to do: gdbarch_info_init_current (&info); but since architectures have an independent lifetime from BFD objects it's not clear how I can implement that. Thoughts? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer