From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11580 invoked by alias); 13 Jun 2002 18:06:28 -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 11569 invoked from network); 13 Jun 2002 18:06:27 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 13 Jun 2002 18:06:27 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 705763CA8; Thu, 13 Jun 2002 14:06:28 -0400 (EDT) Message-ID: <3D08DF24.9000700@cygnus.com> Date: Thu, 13 Jun 2002 11:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gdbarch: ABFD no longer available at gdbarch_update_p time References: <20020613151528.GA4688@nevyn.them.org> <3D08C5B7.2010809@cygnus.com> <20020613175057.GA27905@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00102.txt.bz2 > - 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'? It was the case - current_gdbarch could have been pointing to CRIS when you were selecting MIPS. Two things changed: - current_gdbarch is now set to NULL during an architecture update (so that can't be used) - arches is kept sorted with most recently selected always at the front so that arches->gdbarch is ... > Oh, from the > comment below it looks like you mean "the last architecture of this > family". OK. Yes. > 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. Ah, yes, good point. The abi from the binary and the one that was selected. Andrew