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
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/

- Raw text -