Mail Archives: djgpp-workers/2001/03/30/05:32:52
Hi!
Friday, 30 March, 2001 Eli Zaretskii eliz AT delorie DOT com wrote:
EZ> We are trying to add support for core files to the DJGPP port of GDB.
EZ> However, the available documentation which describes what needs to be
EZ> done is, at best, scanty ;-) So I wonder if someone here can help.
EZ> Producing a core file in a format already supported by BFD is not
EZ> easy, because under the default algorithm used by DJGPP's sbrk the
EZ> program's address space may be non-contiguous. This is due to
EZ> peculiarities of various DPMI hosts used on specific platforms,
EZ> most notably Windows, and the fact that the DPMI spec doesn't provide
EZ> any way for the program to specify where in memory will the program's
EZ> code and data be put; you just request a chunk of memory of the size
EZ> you need and get a buffer wherever the DPMI host wants it to be. The
EZ> same problem also makes it next to impossible to reproduce the exact
EZ> way the program's address space was layed out after reading the core
EZ> file.
i think that cygwin in this account is similar to djgpp, so, i think,
cygwin's way to produce and analyze core dumps may be used in djgpp
EZ> (If this is not clear enough, and if someone is interested, I can tell
EZ> more details.)
EZ> We already have a prototype version of code which writes to a disk
EZ> file the program's memory image and some additional information, such
EZ> as the general-purpose registers, segment selectors, etc. But the
EZ> format of the core file is not something BFD can understand.
EZ> For these reasons, we would try first to explore the possibility of
EZ> using a custom core file format, instead of going through BFD.
EZ> However, I cannot find any real documentation of the API used by GDB
EZ> for accessing core files. I'd expect GDB to need a few functions to
EZ> read the core file (or, perhaps, its specific portions), find out the
EZ> values in registers at the point of crash, what was the signal that
EZ> aborted the program, etc. Where can I look for some info about this?
EZ> If someone has experience in providing such kind of core file support,
EZ> could they please post any advice that could be useful, and/or point
EZ> to any docs and code that could be of use to us?
i implemented core files for cygwin some time ago. the core file is
created in elf format.
all committed pages in process address space are written to .mem
sections (adjacent pages go to one section), and additional data such
as register values for all threads and names of all dlls mapped into
process's address space are written into .note sections of
NT_WIN32PSTATUS type. here, too, memory regions allocated for process
may be non-continuous, and their addresses are not known beforehand.
what gdb needs to do when he saw such core file is to open it via
normal bfd calls, scan it for additional info in .note sections and
map all .mem sections. the latter is done automatically, iirc, you
should only make section name to start from ".mem/"
for details, see
bfd/elf.c (elfcore_grok_win32pstatus) -- stub to process .note
sections in cygwin elf core file.
winsup/utils/dumper.cc -- utility to create core file.
gdb/win32-nat.c -- functions to process elf core file.
actually most of this code is dealing with dlls mapped into dumped
process address space -- to reduce size of core file their code
sections are not written to core file, but instead only their path is
written, so gdb will map their code sections from dll itself not from
core file. i don't think that djgpp will need such functionality, so
code will be somewhat simpler.
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -