I've got a target with a ColdFire MFC5484 running Linux 2.6.25. A target application has generated core files we'd like to examine with gdb, offline, on the host system used to build the image. The host system is a PC running Linux 2.6.33.3.
gdb on the host is m68k-linux-gnu-gdb, version 6.7.50.20080107.
Invoking this gdb on the host works fine, as does loading the executable (with symbols). Loading the core file results in gdb complaining that it "can't read core files on this machine".
(gdb) file myExecutable
Reading symbols from /home/blah...blah/myExecutable...done.
(gdb) core-file core.myExecutable.1234
GDB can't read core files on this machine.
(gdb)
Do I need to have all of my libraries and source directories set up in gdb before loading the core file, or is this gdb a version that will only work attached to gdbserver running on a target (and examine the core file on the target only)? Or is there something else more fundamental I'm missing? I'd like to be able to examine a core file without being attached to the system that generated the core dump.
Thanks...
Read the source code for gdb, searching for that error message.
You'll find it "gdb/corefile.c" in a section with the comment:
/* Backward compatability with old way of specifying core files. */
"Old way"? Implies you should be using "the new way" whatever that is. The code is calling find_core_target() and the comments on it say:
/* Find a single core_stratum target in the list of targets and return it. If for some reason there is more than one, return NULL. */
Could it be finding more than one?
The "help text" for the core file command is:
Use FILE as core dump for examining memory and registers.\n\No arg means have no core file. This command has been superseded by the\n\`target core' and `detach' commands.
So you may want to use the "new form".
I was having trouble with gcc and core files yesterday. The command "powerpc-linux-gdb core" didn't work, but "powerpc-linux-gdb --core=core" did in my case.
Tom