Re: [PATCH/RFA] Don't gdbarch_init for core files

[Andrew Cagney <ac131313@cygnus.com>]

> 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