From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10104241440.AA18551@clio.rice.edu>
Subject: Re: Fixed core dumper in dpmiexcp.c
To: broeker AT physik DOT rwth-aachen DOT de (Hans-Bernhard Broeker)
Date: Tue, 24 Apr 2001 09:40:12 -0500 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii), djgpp-workers AT delorie DOT com,
        n_abing AT ns DOT roxas-online DOT net DOT ph
In-Reply-To: <Pine.LNX.4.10.10104241337420.5316-100000@acp3bf> from "Hans-Bernhard Broeker" at Apr 24, 2001 01:48:49 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > > So yes, it may well be that the code computing the actual size of
> > > individual memory blocks is wrong, and thus tries to dump unmapped memory.
> > > As far as I understand the code, it assumes that the whole address range
> > > spanned __djgpp_memory_handle_list[] is mapped, up to
> > > __djgpp_selector_limit, with no holes.
> > 
> > I don't have the code handy: does each handle in the list specify its 
> > starting address and its size?  
> 
> No. Quoting include/crt0.h:
> 
> typedef struct {
>   long handle;
>   unsigned address;
>   } __djgpp_sbrk_handle;
> 
> extern __djgpp_sbrk_handle __djgpp_memory_handle_list[256];
> 
> No size or end address is kept in the __djgpp_memory_handle_list.  In
> principle, the DPMI call mentioned below should be able to retreive the
> size --- but it's a 1.0-only call :-(

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 - that
nightmare of prototype AS code that was never re-written :-P

Or you would need to use unixy sbrk - if we did this you could use a
"standard" core format.

> Well --- maybe it can't, and that's the heart of our dilemma. Or maybe it
> shouldn't have to, if we were to assume that the whole arena (from
> 0x000000000 to __djgpp_selector_limit) is always mapped, without holes.

A really bad assumption ...  Other programs running share our address
space in W9x - and will end up with memory blocks between ours at times.
Those may be freed and the page tables unmapped - so crunch if we touch
them.