Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-ID: <012e01c140ff$cbcdb9e0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: <cygwin@cygwin.com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F199@itdomain002.itdomain.net.au> <20010918225336.G8924@redhat.com> <010a01c140fd$13e3e310$0200a8c0@lifelesswks> <20010919073353.E12960@redhat.com>
Subject: Re: [BUG] cygwin-1.3.3-2 -- making auto-import dlls
Date: Wed, 19 Sep 2001 21:39:51 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

---- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
> The issue here is that a "foreign" DLL is getting loaded into area
that
> cygwin wants to use for its cyheap.  It is immaterial where or if the
> cygwin DLL is relocated.

I *think* I get you. There are *two* similar but not identical issues
with dll relocation. You spoke of one, and I spoke of another.

> As I said, making the cygwin DLL occupy a fixed location would not
solve
> this particular problem.

Yes. I see that now.

> The ld script file issue that I raised would fix the issue of
collisions
> from a DLL that loads after the cygwin DLL, occupying space that
cygwin
> desperately wants to use.  It would not affect the fork relocation
issue.

(This is where the penny dropped)... because that's different right! :].

And the short sumamry is:
*Collision of dlls into the cygwin heap space (immediately after
cygwin1.dll's address space) breaks fork (can't copy the heap).
*Relocation of cygwin1.dll's address space between parent and child
breaks fork (all variable references are now wrong, even for statically
allocated variables.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/