Message-Id:	<200103301443.JAA24895@texas.cygnus.com>
To:	Eli Zaretskii <eliz AT delorie DOT com>
cc:	gdb AT sources DOT redhat DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>,
	djgpp-workers AT delorie DOT com
Subject:	Re: Adding support for core files to DJGPP
Date:	Fri, 30 Mar 2001 09:43:39 -0500
From:	David Taylor <taylor AT cygnus DOT com>
Reply-To:	djgpp-workers AT delorie DOT com

    Date: Fri, 30 Mar 2001 04:06:15 -0500 (EST)
    From: Eli Zaretskii <eliz AT delorie DOT com>

    We are trying to add support for core files to the DJGPP port of GDB.
    However, the available documentation which describes what needs to be
    done is, at best, scanty ;-)  So I wonder if someone here can help.

    Producing a core file in a format already supported by BFD is not
    easy, because under the default algorithm used by DJGPP's sbrk the
    program's address space may be non-contiguous.  This is due to
    peculiarities of various DPMI hosts used on specific platforms,
    most notably Windows, and the fact that the DPMI spec doesn't provide
    any way for the program to specify where in memory will the program's
    code and data be put; you just request a chunk of memory of the size
    you need and get a buffer wherever the DPMI host wants it to be.  The
    same problem also makes it next to impossible to reproduce the exact
    way the program's address space was layed out after reading the core
    file.

If you are designing the core file format for DJGPP, I would recommend
making it an ELF file.  I believe that the Sys V ABI specifies for Sys
V systems much of the core file layout stuff; rather than invent a new
format, I would suggest using that.

In ELF format core files, different address space chunks go into
different sections, so having the address space be non contiguous is
not a problem.

    (If this is not clear enough, and if someone is interested, I can tell
    more details.)

    We already have a prototype version of code which writes to a disk
    file the program's memory image and some additional information, such
    as the general-purpose registers, segment selectors, etc.  But the
    format of the core file is not something BFD can understand.

With ELF files, things like registers go into their own section.  And
if you are multi threaded, each thread's registers go into their own
section.

GDB already has support for this format, so your GDB work would be
minimal if you did something like this.  Ditto for BFD.

    For these reasons, we would try first to explore the possibility of
    using a custom core file format, instead of going through BFD.
    However, I cannot find any real documentation of the API used by GDB
    for accessing core files.  I'd expect GDB to need a few functions to
    read the core file (or, perhaps, its specific portions), find out the
    values in registers at the point of crash, what was the signal that
    aborted the program, etc.  Where can I look for some info about this?

If you really want a custom core file format, for the GDB part, look
at the struct 'core_fns' (gdbcore.h) and the functions in corelow.c.
For examples, look at core-*.c.

Good luck.

- Raw text -