From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8293 invoked by alias); 16 May 2002 23:24:27 -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 8285 invoked from network); 16 May 2002 23:24:24 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 16 May 2002 23:24:24 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA09142; Thu, 16 May 2002 16:24:05 -0700 (PDT) Message-ID: <3CE43C60.9197EDD@redhat.com> Date: Thu, 16 May 2002 16:24:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00681.txt.bz2 Andrew Cagney wrote: > > > 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. Will they? What if, for instance, gdb defaults to sparc32, but the corefile is sparc64? > 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? Correct. And I think the worrisome case is when there is no symbol file. > 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