From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17769 invoked by alias); 17 May 2002 00:33:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17762 invoked from network); 17 May 2002 00:33:46 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 17 May 2002 00:33:46 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A0A983E3D; Thu, 16 May 2002 20:33:55 -0400 (EDT) Message-ID: <3CE44FF3.30605@cygnus.com> Date: Thu, 16 May 2002 17:33:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Snyder Cc: thorpej@wasabisystems.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Don't gdbarch_init for core files References: <20020509185824.U3435@dr-evil.shagadelic.org> <3CDB38BB.4030807@cygnus.com> <20020509212134.W3435@dr-evil.shagadelic.org> <3CDDD7ED.9080302@cygnus.com> <3CE43C60.9197EDD@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00687.txt.bz2 > - set_gdbarch_from_file (core_bfd); >> > + /* If the core's arch is known and different from the current, >> > + reinitialize gdbarch based on the core file. */ >> > + >> > + current_arch_info = gdbarch_bfd_arch_info (current_gdbarch); >> > + if (core_bfd->arch_info->arch != bfd_arch_unknown >> > + && core_bfd->arch_info->arch != current_arch_info->arch) >> > + set_gdbarch_from_file (core_bfd); > >> >> is [almost] no different to deleting the call - GDB isn't yet built with >> multiple architectures so the two architectures will always be identical. > > > Will they? What if, for instance, gdb defaults to sparc32, but > the corefile is sparc64? The bfd_arch_sparc would be the same in both cases but bfd_mach... would be different. Any way my bfd_arch_compatible() suggestion has a bug mind: const bfd_arch_info_type * bfd_arch_get_compatible PARAMS (( const bfd *abfd, const bfd *bbfd)); A new interface would be needed. Andrew