From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23862 invoked by alias); 10 May 2002 01:58:28 -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 23855 invoked from network); 10 May 2002 01:58:27 -0000 Received: from unknown (HELO dr-evil.shagadelic.org) (208.176.2.162) by sources.redhat.com with SMTP; 10 May 2002 01:58:27 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 376F49869; Thu, 9 May 2002 18:58:25 -0700 (PDT) Date: Thu, 09 May 2002 18:58:00 -0000 From: Jason R Thorpe To: gdb-patches@sources.redhat.com Subject: [PATCH/RFA] Don't gdbarch_init for core files Message-ID: <20020509185824.U3435@dr-evil.shagadelic.org> Reply-To: thorpej@wasabisystems.com Mail-Followup-To: Jason R Thorpe , gdb-patches@sources.redhat.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dMdWWqg3F2Dv/qfw" Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Wasabi Systems, Inc. X-SW-Source: 2002-05/txt/msg00315.txt.bz2 --dMdWWqg3F2Dv/qfw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1242 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. -- -- Jason R. Thorpe --dMdWWqg3F2Dv/qfw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=core-patch Content-length: 506 Index: corelow.c =================================================================== RCS file: /cvs/src/src/gdb/corelow.c,v retrieving revision 1.21 diff -u -r1.21 corelow.c --- corelow.c 5 May 2002 01:15:13 -0000 1.21 +++ corelow.c 10 May 2002 01:40:13 -0000 @@ -321,8 +321,6 @@ error ("\"%s\": Can't find sections: %s", bfd_get_filename (core_bfd), bfd_errmsg (bfd_get_error ())); - set_gdbarch_from_file (core_bfd); - ontop = !push_target (&core_ops); discard_cleanups (old_chain); --dMdWWqg3F2Dv/qfw--