X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Tue, 24 Apr 2001 19:28:00 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp workers list <djgpp-workers AT delorie DOT com>
cc:	sandmann AT clio DOT rice DOT edu, n_abing AT ns DOT roxas-online DOT net DOT ph
Subject:	Re: Fixed core dumper in dpmiexcp.c
In-Reply-To:	<3405-Tue24Apr2001201731+0300-eliz@is.elta.co.il>
Message-ID:	<Pine.LNX.4.10.10104241925100.5316-100000@acp3bf>
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, Eli Zaretskii wrote:

> > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> > Date: Tue, 24 Apr 2001 09:40:12 -0500 (CDT)
> > 
> > Without the size of each block you can't reliably do a dump.  To get the
> > size of each block we would have to add this to the sbrk() code
> 
> Does catching Page Faults during dumping and longjmp'ing to dump the
> next page sound like a possible band-aid?

Hmm... sounds like jumping to the next block would make more sense. I.e.
assume that it's only the size we got wrong, but there's still no hole
inside the block represented by one entry in the
__djgpp_memory_handle_list[].

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -