This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 <thorpej@wasabisystems.com>
Attachment:
core-patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |