Date:	Wed, 25 Apr 2001 09:01:41 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>,
	djgpp workers list <djgpp-workers AT delorie DOT com>,
	n_abing AT ns DOT roxas-online DOT net DOT ph
Subject:	Re: Fixed core dumper in dpmiexcp.c
In-Reply-To:	<10104242208.AA18766@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010425090111.22758D-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 Tue, 24 Apr 2001, Charles Sandmann wrote:

> This is also making the dump a much riskier thing - we've already had 
> one exception and now we plan to potentially cause a bunch more while
> dumping on an environment with unknown stability.
> 
> You may also dump several additional MB's of memory which don't belong to
> you.
> 
> We really just need to add the memory block lengths someplace.  Maybe a
> good incentive to re-write sbrk() in C :-)

I agree that the Right Way would be to add this info to the memory
handle structure.  The suggestion to longjmp out of the Page Fault was
meant to provide a short-term band-aid to allow the development of the
core file support to proceed with the current sbrk.

Since the core file support will probably start as a separate library,
we could supply a modified crt0.S there with an improved sbrk.

- Raw text -