Re: Adding support for core files to DJGPP

Re: Adding support for core files to DJGPP

[David Taylor]

    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.

Re: Adding support for core files to DJGPP

[Eli Zaretskii]

> Date: Fri, 30 Mar 2001 09:43:39 -0500
> From: David Taylor <taylor@cygnus.com>
> 
> If you are designing the core file format for DJGPP, I would recommend
> making it an ELF file.

It sounds like that: you are the second person (out of two who
replied) who suggested that.  Thanks.

> 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.

Where can I find these specifications that you mention above?

> 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.

Thanks again.

> Good luck.

We'll need it, I know ;-)

Re: Adding support for core files to DJGPP

[J.T. Conklin]

>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>> Date: Fri, 30 Mar 2001 09:43:39 -0500
>> From: David Taylor <taylor@cygnus.com>
>> 
>> If you are designing the core file format for DJGPP, I would recommend
>> making it an ELF file.

Eli> It sounds like that: you are the second person (out of two who
Eli> replied) who suggested that.  Thanks.

For a host environment like DJGPP, I agree with the recommendation for
ELF crash dumps.  

However, I wanted to mention that for embedded environments, it may be
better to use a custom crash dump format.  One requirement I had was I
had to write dumps to streaming media (in other words, no seeks).  I
suspect I could have written ELF dumps by doing two passes over the
system (one to compute the offsets, another to write the dump), it was
simpler to use a format designed for streaming from the get go.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: Adding support for core files to DJGPP

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 30 Mar 2001 11:43:59 -0800
> 
> For a host environment like DJGPP, I agree with the recommendation for
> ELF crash dumps.  
> 
> However, I wanted to mention that for embedded environments, it may be
> better to use a custom crash dump format.  One requirement I had was I
> had to write dumps to streaming media (in other words, no seeks).  I
> suspect I could have written ELF dumps by doing two passes over the
> system (one to compute the offsets, another to write the dump), it was
> simpler to use a format designed for streaming from the get go.

Is there any place one can see the code or docs of what you've
written?

Re: Adding support for core files to DJGPP

[egor duda]

Hi!

Monday, 02 April, 2001 Eli Zaretskii eliz@is.elta.co.il wrote:

>> all committed pages in process address space are written to .mem
>> sections

EZ> I don't see .mem sections mentioned anywhere in the SysV ABI documents
EZ> available from http://www.sco.com/developer/devspecs/ .  Did I miss
EZ> something?  Is there any other documentation about ELF available
EZ> somewhere, where these sections are documented?

i think ".mem/" sections is just a common convention gdb supports. System V
ABI specification explicitly says
(at http://www.sco.com/developer/gabi/latest/ch4.eheader.html )
"Although the core file contents are unspecified, type ET_CORE is reserved to
mark the file."

so i suppose the best way is to use the gdb and/or cygwin's dumper sources.
actually, all you have to do is

          sprintf (sect_name, ".mem/%u", sect_no);
          sect_flags = SEC_HAS_CONTENTS | SEC_ALLOC | SEC_LOAD;
          sect_size = memory_block_size;
          sect_vma = (bfd_vma) (memory_block_base_address);

and then write memory region contents to section via bfd_set_section_contents ().

>> winsup/utils/dumper.cc -- utility to create core file.

EZ> Does this mean that the segfaulting application itself doesn't write
EZ> the core file?

no, "kernel", i.e. cygwin1.dll in case of cygwin, is doing the job. when
application triggers exception that is supposed to cause core dump,
cygwin1.dll calls external utility passing crashed program pid and
path to it. this utility scans crashed program address space and
writes needed portions of it to the core file. so crashed program
address space isn't changed while core is being dumped.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

Re: Adding support for core files to DJGPP

[Eli Zaretskii]

> Date: Fri, 30 Mar 2001 14:29:21 +0400
> From: egor duda <deo@logos-m.ru>
> 
> i implemented core files for cygwin some time ago. the core file is
> created in elf format.

Thanks for the info.

> all committed pages in process address space are written to .mem
> sections

I don't see .mem sections mentioned anywhere in the SysV ABI documents
available from http://www.sco.com/developer/devspecs/ .  Did I miss
something?  Is there any other documentation about ELF available
somewhere, where these sections are documented?

> winsup/utils/dumper.cc -- utility to create core file.

Does this mean that the segfaulting application itself doesn't write
the core file?

Re: Adding support for core files to DJGPP

[H . J . Lu]

On Fri, Mar 30, 2001 at 12:34:12PM -0500, David Taylor wrote:
> 
> Some of this information is available on the web.  I know that some of
> the Unix API stuff is available on the web site for the "The Open
> Group"; I don't know whether the core file and ELF file ABI stuff is
> available there or not, though.
> 
> You might also try SCO.

I think you can most of things from

http://www.sco.com/developer/devspecs/


H.J.

Re: Adding support for core files to DJGPP

[David Taylor]

    Date: Fri, 30 Mar 2001 10:34:29 -0500 (EST)
    From: Eli Zaretskii <eliz@delorie.com>

    > Date: Fri, 30 Mar 2001 09:43:39 -0500
    > From: David Taylor <taylor@cygnus.com>

    > 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.

    Where can I find these specifications that you mention above?

Once upon a time, AT&T published (in conjuction with Prentice-Hall) a
set of books that describe the standard.  Titles like "System V
Application Binary Interface", "System V Application Binary Interface:
SPARC Processor Supplement", and "Understanding ELF Object Files and
Debugging Tools".  If you want to go the book route, I'd suggest
trying any good technical bookstore.

Some of this information is available on the web.  I know that some of
the Unix API stuff is available on the web site for the "The Open
Group"; I don't know whether the core file and ELF file ABI stuff is
available there or not, though.

You might also try SCO.

Re: Adding support for core files to DJGPP

[Eli Zaretskii]

> Date: Fri, 30 Mar 2001 14:29:21 +0400
> From: egor duda <deo@logos-m.ru>
> 
> 
> 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

[lots of useful advice omitted]

Thanks!  I will look into places you mentioned.

Re: Adding support for core files to DJGPP

[egor duda]

Hi!

Friday, 30 March, 2001 Eli Zaretskii eliz@delorie.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

Adding support for core files to DJGPP

[Eli Zaretskii]

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 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.

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 someone has experience in providing such kind of core file support,
could they please post any advice that could be useful, and/or point
to any docs and code that could be of use to us?

Thanks in advance for any help.