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

> 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 :-)

- Raw text -