X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=nCq8wQ37BYQR3BSvslku7daY2yhN6V6oMs3PASWn3IqnpFe+bGgEn
	AwoHXomixocYExO9tHTkIm+ogyd1/DEj/8c2sneS9lBXHLSo4ssprOP1jibaxfFw
	pvc8V9Bwh6jsnkiZcx7529qN8Rmz3/2kU7eWOGLlcyEzqHB9dgSEnI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=UsSKUk95BO2S6sPXzn/tVu1mURs=; b=PDjElBzNoqk3lDYSwEBylsnCzcNg
	kQGU15ZGGB94qG2Rh/dGd132KuTRABjkFU+sp4xlG5uS2GNrRqZ2v7G0QCvsjXHz
	zBBE9n8lsNkeKiMr9NNTFnd8SdXMtLhJ9QJNj45b9bsEKU9nG6S8ZoUz1trl0tvJ
	apnfsWpFLPdjc2A=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-101.4 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=downwards, Apart, reserved
X-HELO: drew.franken.de
Date: Fri, 9 Feb 2018 14:11:41 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Regression for OCaml introduced by rebase 4.4.4
Message-ID: <20180209131141.GL30794@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <000001d3a0d2$9f604860$de20d920$@cl.cam.ac.uk> <20180208151549 DOT GA32555 AT calimero DOT vinschen DOT de> <E51C5B015DBD1348A1D85763337FB6D90189A8933F AT Remus DOT metastack DOT local> <20180209114048 DOT GK30794 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="0z5c7mBtSy1wdr4F"
Content-Disposition: inline
In-Reply-To: <20180209114048.GK30794@calimero.vinschen.de>
User-Agent: Mutt/1.9.1 (2017-09-22)

--0z5c7mBtSy1wdr4F
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb  9 12:40, Corinna Vinschen wrote:
> On Feb  9 11:29, David Allsopp wrote:
> > > Apart from that, not only Cygwin DLLs but also the Windows system DLLs
> > > are all loaded and relocated to the area beyond 0x1:80000000, so
> > > relocation beyond the 32 bit address space is no generic problem in
> > > Windows.  Why isn't that possible in FlexDLL?  I don't understand thi=
s.
> > > To me this looks like a bug in FlexDLL, not a requirement to let cert=
ain
> > > DLLs slip through the cracks.
> >=20
> > There's a more full explanation of what and why for flexdll here:
> > https://github.com/alainfrisch/flexdll/blob/master/README.md. I
> > believe it's not unrelated to some of the black magic going on in
> > Cygwin's autoload.cc, but without (at least at the moment), quite as
> > much self-modifying code.
> > [...]
> > I guess one can argue over whether that's a bug or a limitation, but
> > the problem we face is that we can engineer it so that our DLLs and
> > executables are within a 2GB range (having looked again at this in
> > even more detail, we could just as readily do this with addresses >
> > 0x200000000), but we still run the risk of rebase messing up the DLLs.
> >=20
> > However, we'll scratch our heads some more on possible alternative
> > solutions, since having a flag for DLLs which says "keep us within a
> > 2GB range somewhere" sounds even more less likely to get merged than
> > my previous suggestion.
>=20
> Two points:
>=20
> - You are aware that the main executable of 64 bit Cygwin processes are
>   loaded to 0x1:00400000, right?  The 2 GB offset problem is already
>   imminent.

...and you must not use the 0x0:80000000 - 0x1:00000000 area because that's
reserved for thread stacks.

To clarify, the full layout requirements:

- 0x0:00000000 - 0x0:80000000	Windows
- 0x0:80000000 - 0x1:00000000	Cygwin pthreads (including main thread)
- 0x1:00000000 - 0x1:80000000	Executable
- 0x1:80000000 - 0x2:00000000	Cygwin DLL
- 0x2:00000000 - 0x4:00000000	Rebased DLLs
- 0x4:00000000 - 0x6:00000000	Non-rebased DLLs (hashed default addresses
				generated by binutils ld with
				-auto-image-based (default on Cygwin))
- 0x6:00000000			Start Address Heap, growing upwards
- 0x8:00000000 - 0x700:00000000	Mmaps, allocated downwards
- 0x700:00000000 and beyond	Windows


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--0z5c7mBtSy1wdr4F
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp9ng0ACgkQ9TYGna5E
T6Bifg//b2ak7vvqei7/fQLHkpRe1nTVK+z1nenZTlWEqutH0UG7L2oqOqnZy/od
dmVaTPKCSGMWfvwrRNsG5C2WLBMT64k5S4XZcmToXEaaq9xrHF08Xh6z00/KPzSZ
reayRA+omVzP4aGFOIU7vkAwmjr3Dnqw8K3c2zdn2r6lbREiQp6NdzvtH/X7iGds
NEVhJKqxwiOepze9KNII7TfgyGINTsRxVB59yjU2ktfvK64f99IE5wMI2WaTZjFr
gKbQCJVLcd32VQGAXeWKec8JY5vte0wLjrAjHt3By2IdDlbs7h2P+uNn2NSGo9R9
4oslK4PZ6iYCUXguHMkGWCwC7mYTbN/byJ8MdkdpWiUvAFLTCiE7OVtrlYrZ1dSl
u06bHaQyiCTZIbdyDc3h68SNs9UutyWE3jNF4uCEqARh3PhQvTC8N0UVv/g603Qq
p5v5kvjVyG0zrJH++0ODaDHDYRu3k5fCI5n2aH+JCNnWdBSKMO9953SNZDK7+GAb
A9RAdQWAV6IFPC+aBEceU/PsY44S4beLI7HS9LSKqOckd4QGWf6BH9/j1MJ/D5Vl
5y9gQrJq1UxFhemkFPHr/WtWgJNTeXyksI2diz3YuLAc8WOYwRXVHn3UjRMMZuRi
4MbWiwwIQ0U8T3WCGx4783Xv2ApLHtZBQFOHO9+fi+IiBPi+uco=
=xbKs
-----END PGP SIGNATURE-----

--0z5c7mBtSy1wdr4F--