Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: David Taylor <taylor@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sources.redhat.com, Charles Sandmann <sandmann@clio.rice.edu>,
	djgpp-workers@delorie.com
Subject: Re: Adding support for core files to DJGPP
Date: Fri, 30 Mar 2001 06:44:00 -0000	[thread overview]
Message-ID: <200103301443.JAA24895@texas.cygnus.com> (raw)

    Date: Fri, 30 Mar 2001 04:06:15 -0500 (EST)
    From: Eli Zaretskii <eliz@delorie.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.


             reply	other threads:[~2001-03-30  6:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-30  6:44 David Taylor [this message]
2001-03-30  7:49 ` Eli Zaretskii
2001-03-30 11:44   ` J.T. Conklin
2001-03-31  1:43     ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2001-03-30  9:34 David Taylor
2001-03-30 11:14 ` H . J . Lu
2001-03-30  1:10 Eli Zaretskii
2001-03-30  2:32 ` egor duda
2001-03-30  3:28   ` Eli Zaretskii
2001-04-02  1:19   ` Eli Zaretskii
2001-04-02  3:20     ` egor duda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200103301443.JAA24895@texas.cygnus.com \
    --to=taylor@cygnus.com \
    --cc=djgpp-workers@delorie.com \
    --cc=eliz@delorie.com \
    --cc=gdb@sources.redhat.com \
    --cc=sandmann@clio.rice.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox