From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10103290510.AA17496@clio.rice.edu>
Subject: Re: dpmiexcp.c with core dumping
To: n_abing AT ns DOT roxas-online DOT net DOT ph (Nimrod A. Abing)
Date: Wed, 28 Mar 2001 23:10:50 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <3.0.1.32.20010328133149.006aec58@wingate> from "Nimrod A. Abing" at Mar 28, 2001 01:31:49 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Attached to this message is dpmiexcp.c modified to provide core dumping for
> DJGPP programs. 

(And DJ Delorie asked:)

>How difficult would it be for the module to create a COFF format core
>file, similar to what bfd/gdb already knows how to read?  That would
>make it a lot easier to add core support to gdb later.

I would also like to see a "standard" format, but there is a problem
when we use the non-move sbrk().  Since Windows just loves returning 
non-contiguous memory blocks all over the place (sometimes below the
base address, which makes it look like a 4Gb address space) the core
files are huge unless they are dumped in pieces.  This also makes it
a real pain to process the core files also...

I believe we could use the standard core format if we used the unixy-sbrk,
but some extension is needed with the default sbrk().

Or at least this is what I remember from a few years ago.  

I'm actually happy to see work moving in this area - if someone looks at
an old source for dpmiexcp I had some comments in there about core stuff
at one time...

Thanks, Nimrod.

P.S.  Not on list, just visiting :-)