Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Mon, 20 Nov 2000 20:13:58 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: Cygwin mailing list <Cygwin AT cygwin DOT com>, GCC Bugs <gcc-bugs AT gcc DOT gnu DOT org>,
        GCC Patches <gcc-patches AT gcc DOT gnu DOT org>
Subject: Re: Reason for cygwin GCC 2.97 non-bootstrap found
Message-ID: <20001120201358.H11780@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: Cygwin mailing list <Cygwin AT cygwin DOT com>,
	GCC Bugs <gcc-bugs AT gcc DOT gnu DOT org>,
	GCC Patches <gcc-patches AT gcc DOT gnu DOT org>
References: <200011202245 DOT eAKMjjN27680 AT plmlir3 DOT mail DOT eds DOT com> <20001120154222 DOT O17712 AT wolery DOT stanford DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <20001120154222.O17712@wolery.stanford.edu>; from zackw@Stanford.EDU on Mon, Nov 20, 2000 at 03:42:23PM -0800

On Mon, Nov 20, 2000 at 03:42:23PM -0800, Zack Weinberg wrote:
>On Mon, Nov 20, 2000 at 05:45:26PM -0500, Kelley Cook wrote:
>> After much binary searching this weekend, I discovered the reason why
>> Cygwin hasn't been able to bootstrap since late August.
>...
>>         * ggc-page.c (alloc_page): If HAVE_MMAP_ANYWHERE and we're
>>         asked for one page, allocate GGC_QUIRE_SIZE of them and put
>>         the extras on the free list.
>
>I am not familiar with Cygwin internals either.  However, the
>underlying Windows primitives - MapViewOfFile, UnmapViewOfFile - do
>not appear to support allocating a large chunk of memory and then
>freeing bits and pieces of it, which is what the above winds up
>doing.  (I am basing this on a rapid skim of the Windows API docs
>available, with effort, from msdn.microsoft.com.  I may be wrong.)

I think that this use should be supported.  UnmapViewOfFile doesn't seem
to be too picky about what it is releasing.  I've seen it unmap part of
the text segment, for instance.

If mmap is broken, then we'll certainly fix it.  It sounds like it should
be easy to duplicate the breakage from your description.

>That change was a marginal performance hack and I don't think it'd do
>any harm to scrap it.  However, I am currently testing a patch which
>moves the memory allocation mess into libiberty.  (It's a modified
>version of the patch by Alexandre Oliva and Laurnyas Bivenis - less
>complex, hopefully just as effective.)  I'd be curious to know how it
>works on cygwin.  Patch is appended.
>
>It'd probably be a good idea to add additional autoconf and #ifdef
>logic so that xvalloc.c uses VirtualAlloc() instead of Cygwin's mmap
>on Win32 hosts.

Reading what xvalloc.c does, I think it makes sense to use cygwin's heap
to allocate the memory, just to avoid having one implementation trip
over another.  We could easily provide either valloc or memalign, if
needed.  I'm sort of suprised that this isn't available now, in fact.

Is there any reason not to just use cygwin's heap?

cgf

>WARNING: This patch temporarily removes the ability to allocate
>objects larger than one page with ggc_alloc.  I haven't yet had any
>problems, but a ridiculously huge switch statement might trip over the
>limitation.
>
>NOTE: There are a bunch of technically unrelated cleanups to the
>libiberty configure.in in here.
>[snip]

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com