This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Reading Linux core dumps in gdb for CRIS
- To: Orjan Friberg <orjan dot friberg at axis dot com>
- Subject: Re: Reading Linux core dumps in gdb for CRIS
- From: Daniel Jacobowitz <drow at mvista dot com>
- Date: Mon, 5 Nov 2001 13:42:07 -0500
- Cc: gdb-patches at sources dot redhat dot com
- References: <3BE6DB12.3E8BAA29@axis.com>
On Mon, Nov 05, 2001 at 07:31:46PM +0100, Orjan Friberg wrote:
> 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.
Are you reading the corefile in on the native debugger in the same way
(with the same sequence of commands)? If you are, I'd be very
surprised if it works - unless GDB doesn't parse the prologue on i386
maybe?
Don't use symbol-file; use file (or exec-file?) or specify the file on
gdb's command line. Then we will open the file and map it, and
everything will work out as expected.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer