From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19149 invoked by alias); 12 May 2002 02:48:11 -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 19142 invoked from network); 12 May 2002 02:48:10 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 12 May 2002 02:48:10 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 584483E07; Sat, 11 May 2002 22:48:17 -0400 (EDT) Message-ID: <3CDDD7ED.9080302@cygnus.com> Date: Sat, 11 May 2002 19:48: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: thorpej@wasabisystems.com, Michael Snyder Cc: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00414.txt.bz2 > How about this? > > * corelow.c (core_open): If the core's arch is known and > different from the current, reinitialize gdbarch based on > the core file. > Hmm, thing is: > - 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. Looking at the date/author of the original patch [and making a wild guess], I think the original change was related to debugging 32 bit core files on a SPARC64 system. Michael? For the moment, bfd's compatible() might be the best test (does it give the effect you're looking for?). The other approach is to enhance the relevant architecture vectors so that they don't change the architecture for cases like this. I think, eventually, the ABI/OS stuff will help solve this problem. Anway, what ever the change, it will need plenty comments :-) enjoy, Andrew