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=lgn/ppHeyf1xT3kiQOFxdKaCQKITRdWJ8bxZTnBGXCO+dMPtklRUa
	ei9dQj9vdPazvJ/2TyG4ip2IIrqRhCQZ4qmMYThEMWxrFXWeFguOUsx+9EqHto5J
	o2Df+PwoxThezgbf5h3AooeAbimoQsaX+SetftGRh3grvYG1h+3/s0=
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=9+mJpXue0l3PUTfduTgRvPYCGN0=; b=w3cQ9DFZq4qTEyK6juwaUt9Yesck
	UspDRZZh7ZOF+CGNPBM+wYLPZ0aU4lsNaM2aHOjweDL0cB3ST6NZMXonoCqd2cZ6
	aqE8zmBA4jb/3Jd9/b6mukkAzsOq98V16CjUd7m71qkziIJhemB8LiPYlBWrWWjt
	ki3b6WfjUCAJmnU=
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=
X-HELO:	drew.franken.de
Date:	Fri, 9 Feb 2018 18:11:00 +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:	<20180209171100.GM30794@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> <E51C5B015DBD1348A1D85763337FB6D90189A89981 AT Remus DOT metastack DOT local>
MIME-Version:	1.0
In-Reply-To:	<E51C5B015DBD1348A1D85763337FB6D90189A89981@Remus.metastack.local>
User-Agent:	Mutt/1.9.1 (2017-09-22)

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

On Feb  9 13:12, David Allsopp wrote:
> Corinna Vinschen wrote:
> > On Feb  9 11:29, David Allsopp wrote:
> > > [...]
> > > When this was originally encountered for 64-bit MSVC (this was all
> > > added before Cygwin64 existed), the solution at the time was to keep
> > > the preferred base addresses low, but in reality what's really
> > > required is that everything is within a 2GB window somewhere in the
> > > address space.
> > >
> > > 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.
> > >
> > > 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.
>=20
> Our executables are also compiled via flexdll's flexlink which sets
> --image-base in its call to the linker. I don't think the Cygwin DLL
> does anything which alters that, right?

It doesn't.  It can't, actually.  But you're breaking assumptions Cygwin
is relying on under the limitations Windows has.

> Another "fix" I tried while
> investigating was to change the --image-base we specified to be within
> 2GB of where rebase has put the DLLs, which also worked.
>=20
> > - What about adding an addition jump table?  The relocation would only
> >   have to point to the jump table in the vicinity of the DLL in
> >   question, the jump table points to the actual 64 bit address.
>=20
> That was what our head-scratching has arrived at too, which I'm in the
> process of doing.

\o/

> > I'm curious why this isn't done yet.
>=20
> I'm hoping that doing it is going to reveal that it simply wasn't
> considered in 2008, rather than that it was and there was an issue
> with it (I think it will just be that it wasn't thought of - like
> Cygwin at that time in 2008, our x86_64 on Windows support was
> extremely limited and not receiving much engineering focus).

We had similar problems back then.  The idea to move the executable
and DLLs beyond the lower 32 bit area was nice as such... only GCC
didn't support it at the time at all.  We had to add the x86-64 medium
and large cmodel implementation to GCC to make this work first.
Cygwin executables are compiled with --mcmodel=3Dmedium, IIRC.


Corinna

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

--WRT3RXLOp/bBMgTI
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp91iQACgkQ9TYGna5E
T6DTrQ/+Oiwa19aVntatxulKJ7QEgauDKAT4DrbB8n3pPuOyb/yn1pyjGiGKgZv+
0qkc8QqWh8thGLO6H8cG6qf6+q3uTMbHrpKQ5HsayPXj4m8ua7rw4cJUn6P1PT7k
aqyXz5jskaUwcq50fuFdjIcgJ7B8rIDh8n60sUx0QXmEpxKnHT9N+5Pp/LObq5Ef
VUsvxLc4L2XZtj8/9xqFHHUg5Qs+kxdVAuU3Q5gcobZAgccSQVLtNOv+PFv5xWzB
8laoOJVftxD+ByFgBsJ5xAf+55fSY0P4mKvVJH8V2NsHPYCVizQKWzrwonlrGQ8O
yppqs3+LICODgnJvlLi++GpKBOms0CslzaXAcZ0Ad6DrZBsJDIulJ8Atz3/VoUbw
vgjvv7ikcbL7uDcaY7cbQbWXVgHL9a87hYWqlHWl82y0S+BrqpzhZ9cPFBZ+bEHl
bXh7urZpDCVwb0lQSrvsC4frhdQ7uzewQy6A/TieRVrWhGv87ei2oGJKTsrN1D3d
Aqk/g5RQIuaGEmW0vMaidkoVQA7rov2q2zYx+PfgU+sin1EbJuEiwSNYIcJvzNcU
lVbekehG4ToK5LxiKymuVIAddh5Di5r+j/XhOFWyMWgL1YMmTxq2Cti2D2s4UC2T
iE0t7bIfhzbEZxUXqe2EHSt7LOCuKYQNUii0+j44jrSdg8WgPYk=
=tVvb
-----END PGP SIGNATURE-----

--WRT3RXLOp/bBMgTI--

- Raw text -