Date:	Wed, 25 Apr 2001 12:01:05 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Nimrod A. Abing" <n_abing AT ns DOT roxas-online DOT net DOT ph>
cc:	djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu,
	broeker AT physik DOT rwth-aachen DOT de
Subject:	Re: Fixed core dumper in dpmiexcp.c
In-Reply-To:	<3.0.1.32.20010425154212.006d5b7c@wingate>
Message-ID:	<Pine.SUN.3.91.1010425115735.24299F-100000@is>
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

On Wed, 25 Apr 2001, Nimrod A. Abing wrote:

> Yup, an improved sbrk -- one that records the block lengths would be a
> better solution. One reason, the core dumper will just use the
> __djgpp_memory_handle_list directly instead of using its own internal data
> structure.

Feel free to modify sbrk, if you like.  It will be a welcome change, I 
think.

> As for making the core file support a separate library, the original
> version did just that however it chained into the existing exception
> handler -- i.e. it chained into the default djgpp exception handler so
> after the core dump it would print the cftb. In this case, the register
> values especially eip differed in the core dump and in the cftb output, the
> register values in the core dump are wrong. I merged the core dumper code
> with dpmiexcp.c to correct this and added some variables to let the user
> tweak the core dumper.

I was thinking along the lines of providing the modified dpmiexcp.c (and 
maybe a modified crt0.S) in this separate library.  If you say something 
like "gcc foo.c -lcore", these modified versions are linked in instead of 
the stock ones in libc.a.

- Raw text -