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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


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.