From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31826 invoked by alias); 10 May 2002 03:04:22 -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 31817 invoked from network); 10 May 2002 03:04:20 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 10 May 2002 03:04:20 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6B6DD3DB9; Thu, 9 May 2002 23:04:27 -0400 (EDT) Message-ID: <3CDB38BB.4030807@cygnus.com> Date: Thu, 09 May 2002 20:04: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 Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Don't gdbarch_init for core files References: <20020509185824.U3435@dr-evil.shagadelic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00316.txt.bz2 > As discussed on gdb@, there is a problem involving gdbarch and core > files. > > At least GNU/Linux and NetBSD identify executables using note sections. > Many targets use this to select the OS/ABI variant for the target. > > The problem is that if you are debugging a core file, the core file is > loaded after the executable, and the current code re-initializes the > current gdbarch based on the core file. > > Since the core file lacks the same markings as the executable, the > gdbarch that results is unable to debug the executable+core. > > There are other problems, as well. The core file often doesn't have > the same flags as an executable -- consider the flags the MIPS target > uses to decide between o32, o64, n32, etc. These flags may not be > present in the core file (indeed -- the core file is just a memory image, > and doens't really have an "ABI", per se). The ABI, again, really comes > from the executable. > > At the very least, it has befuddled Daniel and me :-) > > The following patch fixes this problem (which can be easily demonstrated > by simply doing "gdb a.out a.out.core" on any target that supports OS/ABI > variants). > > * corelow.c (core_open): Don't reinitialize the current > gdbarch. Given this original patch: http://sources.redhat.com/ml/gdb-patches/2000-04/msg00483.html is the exact reverse, something else must be needed. Instead of removing the call, is it possible to reasonably detect if the core file belongs to the current architecture (either in corefile.c) or in gdbarch_FOO_init(). Andrew