This is the mail archive of the
mailing list for the GDB project.
Re: Adding support for core files to DJGPP
- To: Eli Zaretskii <eliz at delorie dot com>
- Subject: Re: Adding support for core files to DJGPP
- From: David Taylor <taylor at cygnus dot com>
- Date: Fri, 30 Mar 2001 09:43:39 -0500
- cc: gdb at sources dot redhat dot com, Charles Sandmann <sandmann at clio dot rice dot edu>, djgpp-workers at delorie dot com
Date: Fri, 30 Mar 2001 04:06:15 -0500 (EST)
From: Eli Zaretskii <firstname.lastname@example.org>
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
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
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
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.