delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/02/28/09:35:48

From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10002281410.AA19335@clio.rice.edu>
Subject: Re: Fwd: Re: Bug in crt0.S
To: muller AT cerbere DOT u-strasbg DOT fr (Pierre Muller)
Date: Mon, 28 Feb 2000 08:10:56 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <200002280938.KAA15903@cerbere.u-strasbg.fr> from "Pierre Muller" at Feb 28, 2000 10:22:40 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> >  To Charles Sandmann, about the problem of locking :
> >
> >  shouldn't the DPMI server copy the current lock flag for each page
> >that is move by the UNIXY SBRK function ?

Ideally, it should.  Some (like CWSDPMI) do.  Others don't.  Since the
DPMI spec does not mention this behavior, it's not required.  It seems the
"resize" function in DPMI is not used by many products - and therefore
can contain some pretty ugly bugs.  We saw lots of problems in QDPMI 
because of this.  This was another of those obscure reasons the current
non-move sbrk() was made default.

I don't have the list anymore of DPMIserver vs. features/bugs - but I am
sure that some of them do NOT move the lock flag if the resized block is
moved.  This is one of those really ugly bugs, since:

 1) Usually the arena doesn't have to be moved unless you are running 
    nested images (or on something like Windows which shares memory), 
 2) Some DPMI providers automatically lock pages or transparently handle
    page faults in hardware interrupts,
 3) The memory is probably only faulted out on tight memory machines, which
    are becoming more rare.

So, this is a real problem with the unixy sbrk under some DPMI providers in
tight memory.  

> > In that case, the only think would be to ensure that no sbrk call is made
> >inside the lock_data and lock_code functions, no ?

Much worse - you need to make sure that no sbrk() is called after any lock
function is called.  Ever.  This is how Quake did it.  Allocate all the memory
up front, give back a tiny bit (64K?) so libc would be happy.  This 
avoided having to recompute the base when using nearptrs, solved the locked
locations, but was a bit of a pain to design the code that way.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019