From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1174 invoked by alias); 13 Jun 2002 17:50:33 -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 1167 invoked from network); 13 Jun 2002 17:50:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.19.120.103) by sources.redhat.com with SMTP; 13 Jun 2002 17:50:31 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17IYkL-0007KC-00; Thu, 13 Jun 2002 13:50:57 -0400 Date: Thu, 13 Jun 2002 10:50:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: gdbarch: ABFD no longer available at gdbarch_update_p time Message-ID: <20020613175057.GA27905@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020613151528.GA4688@nevyn.them.org> <3D08C5B7.2010809@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D08C5B7.2010809@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00101.txt.bz2 On Thu, Jun 13, 2002 at 12:17:59PM -0400, Andrew Cagney wrote: > >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): > > Interesting, especially given the CRIS target implements it correctly :-) OK, I think I see where I misunderstood. > > > /* 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."); > > > The sequence is: > > - global option is set > - architecture update is forced > -- architecture variant identified (using info, globals, and the last > architecture) This bit I'm a bit fuzzy on. Isn't the point that the last architecture might someday be CRIS - in 'set mips abi'? Oh, from the comment below it looks like you mean "the last architecture of this family". OK. > -- existing architectures searched, if match return > -- if none match, a new architecture is created using the specified > information > > >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? > > Yes, look at cris_gdbarch_init(): > > else if (arches != NULL) > { > /* No bfd available. Stick with the ABI from the most recently > selected architecture of this same family (the head of arches > always points to this). (This is to avoid changing the ABI > when the user updates the architecture with the 'set > cris-version' command.) */ > cris_abi = gdbarch_tdep (arches->gdbarch)->cris_abi; > } > else For MIPS this means that I'm going to have to carry over: osabi some ABI information which may not be available, but I could probably save. The latter would be the case for 'set mips abi auto', if the binary had been loaded under 'set mips abi o32'. We no longer know what the binary's ABI is but that is easy to fix. Am I on track now? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer