From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10107281511.AA18279@clio.rice.edu>
Subject: Re: Make 3.791 on Windows 2000 test
To: eliz AT is DOT elta DOT co DOT il
Date: Sat, 28 Jul 2001 10:11:44 -0500 (CDT)
Cc: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
In-Reply-To: <200107281027.GAA03194@delorie.com> from "Eli Zaretskii" at Jul 28, 2001 06:27:54 AM
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

> Note that now it's cc1 which crashes, not Make.  So maybe Charles is
> right, and Unixy sbrk is the solution.  Hmm...  Maybe try building GCC
> with Unixy sbrk and se if that helps (you will have to do that for
> both gcc.exe and cc1.exe).
> 
> Still, I'd like to try to find the problem in `sbrk' with the default
> algorithm.  It's possible we don't handle address wrap-around
> correctly.

If you get a lower address, we try to address wrap.  On NT the limit set
silently gets truncated from a 4Gb limit to a 2Gb limit (so it can't 
include NT's OS address space).  So, if we try to access the lower memory
block it kills us on the selector limits.

1) I think we need to make sbrk() aware of the wrap issues.
2) I think we should ignore (keep allocated but not touch) any blocks which
 are returned to us lower than the base, and try again.
3) We may need some way to toggle the default for testing to prevent having
 to rebuild everything.  In the past I had an exe which binary patched all
 the EXEs to toggle the default meaning.