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=GZ9Li8CusSW2yYwBoHwh4xv/z6sI87ZtXbH4FT0sN4Kpx3+M6DXHH
	3CskC5WWrypx2gEzPb17ttapRjEqpBHctUa/7T9qJ+s5URxC8zUGT3SLVEGjwHgv
	cSnnRnWRkqSt4uPHYVqNokwoUecfqVivyGAf7TgYwyVn73Bzzay/GI=
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=v2GIPDpHOu1Pp7HeUK4Hr7WllOA=; b=VYSE3LokKihEitqZb1Hfymjuv4Hr
	82swZRbQNnul+j54gRrAPVq22iBk9IrbzVPH6pPO1+FmNXidU/CKyPd/w2ENGyDQ
	AqP8NYSz7gaV9SS/1wuS9bXB5KQ89P2Q6OwGArVHfOMVC505imfdeOpMPC0WYFlk
	UKvNI5+FVoCV7Ms=
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
X-Spam-Score:	-2.9
Date:	Thu, 15 Feb 2018 13:02:42 +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:	<20180215120242.GJ30794@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> <20180209171100 DOT GM30794 AT calimero DOT vinschen DOT de> <E51C5B015DBD1348A1D85763337FB6D90189AA34DC AT Remus DOT metastack DOT local>
MIME-Version:	1.0
In-Reply-To:	<E51C5B015DBD1348A1D85763337FB6D90189AA34DC@Remus.metastack.local>
User-Agent:	Mutt/1.9.1 (2017-09-22)

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

On Feb 15 11:44, David Allsopp wrote:
> Corinna Vinschen wrote:
> > 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
>=20
> <snip>
>=20
> > > > I'm curious why this isn't done yet.
> > >
> > > 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).
> >=20
> > 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.
>=20
> This all seems to be working nicely, though the mcmodel stuff may also
> be part of why this wasn't fixed properly in 2008, which is because of
> data symbols. Everything does seem to be working correctly (there are
> various int symbols in the ocaml runtime which are always requiring
> absolute relocations, not relative ones, from the DLLs), but I'm
> trying to get my head around being certain that that should always be
> the case.
>=20
> gcc -Q --help=3Dtarget seems to show that the default for mcmodel is
> "32", but I'm struggling to find a description of precisely what that
> means? If I compile all the units with -mcmodel=3Dsmall then, as
> expected, gcc starts generating RELOC_REL32 for data symbols as well.
> flexdll then starts creating thunks for data symbols, though the
> Cygwin runtime unsurprisingly blows up before there's time for
> flexdll's sins to become apparent!
>=20
> Is it the case with -mcmodel=3Dmedium that an external data symbol could
> never be referred to via a RELOC_REL32? My reading of it was that that
> would only be the case if  the symbol itself refers to data which is
> large (-mlarge-data-threshold), but it seems to be happening for ints,
> which are clearly "small". Or have I still not properly understood x64
> code models? The remaining question is what the difference between
> -mcmodel=3D32 and -mcmodel=3Dmedium really is?

I don't know what cmodel=3D32 is supposed to be.  The usual models for
x86_64 are small, medium, large.  Small means using 32 bit relocations
for everything.  That's not feasible for Cygwin.  Medium means to use
normal 32 bit relocs for code but an extra trampoline for data (the 32
bit relocs point to a table with the real 64 bit address).  Large means
to use the trampolines for code and data.  Given that Windows DLL entry
point relocation already uses import/export tables anyway, we can get
away with the medium cmodel by default.  I'm not aware of a package
using the large model, though they might exist.

Note:  I'm not a gcc expert, so I'm not sure how the models are
implemented exactly.  Personally I'm just happy that it works :}


HTH,
Corinna

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

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlqFduIACgkQ9TYGna5E
T6CNCw//Rhoqe+k2OdB72VhedEFakcNx0tQiyzaxqcV4titLuBNlm5fTgJNlULRE
w7LGOyKr3tuIUTCukS1y2poFnM6AGInG+8dwRBlkAUoWi6I3sXhbymcXxPJ0x3Bn
UTlGOQGoTO4uRVFNKX0KbkgVXTfU5C65UlP2rkdSaxKyy6Pc9ONSe9aSgnFqsTLa
2DR4TGeBQ7SPi0vFEGSBcWvIVMYHm4BNeCykrGcalqg9hlDWiF2Ed8k/YvZTr189
cyyoQ26aSHQwc7udZTfDbl1BJaNPIDUKjueErht4Z8l6ta/eBzoYGztP45qT67fI
va3wEW7M67lUHb2iVu9ejMVR5pJWzTo9FUpLck7GiQV+TO0nsxjqodYfmTz4PS3J
086ijD0G9xhqQpUdDRF0d/xZ+zehQDcUC42/dM736PTA+d5dtxgEnViyc5Ytfqdg
MBbgxgN7qiMw2k5dHNt6H+3i9x+/XJHgIlfIRonmdmy4UtJ3PxK8RKqsn3CAA+MH
Lo9IcUxt1PTqZljWtgs0ADil0rVDVhoM1KRdcnFCLcXdnkLgRx6yrWvLklEE3RB6
g9PoipqCDECLH4GRajjSGlEcrslqESEpUsdHGxZOQO/xXQ14d686rGwJDxuPb8bH
DTeprcfayEILAi8bk9EhXxAiTi1/wTA73niltboLeuKQHaRbjOE=
=yEyH
-----END PGP SIGNATURE-----

--reSNjdE3Iylkp4B8--

- Raw text -