Reading Linux core dumps in gdb for CRIS

[Orjan Friberg <orjan dot friberg at axis dot com>]

I'm working on support for core dumps in our Linux and gdb ports for
CRIS.  My current Linux tree is a 2.4.12, and to my surprise I found
that Linux doesn't dump executable vm segments by default.  (There's an
#ifdef 1 around a snippet of code in maydump() in binfmt_elf.c which can
be disabled to make the kernel dump executable segments however.)  As a
consequence, the .text section in the core file is missing, and gdb then
fails in xfer_memory when trying to parse the prologue of main (as part
of my INIT_EXTRA_FRAME_INFO).  Example session, with coredumper being
dynamically linked against glibc:

(gdb) symbol-file coredumper
Reading symbols from coredumper...done.
(gdb) core-file core 
Core was generated by `./coredumper'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x804fc

I understand the reason behind not dumping a read-only section, but I'm
curious as to how gdb is supposed to deal with it.  Linux not dumping
the .text section leads me to believe that gdb should be able to get it
from elsewhere, like the original executable.  Following what core_open
does leads to add_to_section_table, which does nothing if the size of
the segment turns out to be 0 (which is why xfer_memory fails later
on).  No target hooks or anything to be able to do something else, and
since it works fine debugging a native core dump on my host Linux
2.2.19  machine (which also doesn't dump .text) the problem must be
elsewhere.  I reckon there must be a higher layer which takes care of
this which is missing in my cross-configuration.

I've searched both the gdb-patches mailing list and the linux kernel
mailing archive on this, but came up pretty much empty handed.   

(I might add that dumping the .text segments allows me to view the core
dump properly.)

-- 
Orjan Friberg              E-mail: orjan.friberg@axis.com
Axis Communications AB     Phone:  +46 46 272 17 68