🚀 go-pugleaf

> The way things work right now, a *host-dependent* function gets called
> to e.g., scan the core file for register contents. I don't see why
> this isn't done through target-dependent code.
> BFD already does the right thing (it reads a FooBar core with the
> FooBar routines) so it seems to me that all the fetch_core_registers
> functions need to me moved out of the xdep files and into the tdep
> files in order to get this to work, but not much more.

If core files were as well documented and as well magic-numbered as
executable files, this would be the right thing.  Most core files are
not distinguishable from files full of binary garbage, though.  (They
tend to contain a lot of binary garbage, with a "u area" dump stuck on
the end.)  So doing BFD-style automatic recognition on all core files
is not going to work.

Some vendors have made more recognizable core file formats (Sun for
example), and BFD can recognize a Sun3 or Sun4 core file (though Sun
didn't really design it with this in mind -- see the BFD sources).
The main problem here is that the include files needed to define most
of these core files only exist on the machine that generates the core
file.  (Most core files contain the "u area" from the kernel, which
itself takes five or ten system-specific include files to describe.)
We could try to produce a new include file to describe each variant on
core files, but many are only documented in the (copyrighted!) include
files on the vendor's system.

A third problem is that core files (like a.out executables) don't
really give you all the information you need -- like the virtual
memory addresses of the various sections.  The assumption is that you
must be running on a FooStation so you must know that all FooStation
executables start at 0x2000 and all FooStation stacks end at 0xF7FFFFFF.

In SVR4, core files are kept in ELF format, which is definitely a step
forward.  Of course, they defined two different kinds of ELF files
(the "linking view" and the "section view" or something like that), so
it's not completely simple.  But the right information is there, it's
well flagged and documented, and GDB should someday be able to support
cross-debugging with ELF core files.

We are currently working on teaching GDB to configure itself
differently for native debugging versus cross debugging.  This should
make it easier to support cross-core-debugging on machines with
reasonable core file formats.

	John Gilmore
	GDB maintainer