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
Message-ID: <012e01c140ff$cbcdb9e0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT cygwin DOT com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F199 AT itdomain002 DOT itdomain DOT net DOT au> <20010918225336 DOT G8924 AT redhat DOT com> <010a01c140fd$13e3e310$0200a8c0 AT lifelesswks> <20010919073353 DOT E12960 AT redhat DOT 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
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 19 Sep 2001 11:48:07.0632 (UTC) FILETIME=[F308A500:01C14100]

---- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT 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/