From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5597 invoked by alias); 15 Feb 2018 12:02:51 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 5586 invoked by uid 89); 15 Feb 2018 12:02:50 -0000 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 Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Feb 2018 12:02:47 +0000 Received: from perth.hirmke.de (aquarius.franken.de [193.175.24.89]) by mail-n.franken.de (Postfix) with ESMTP id 99A35721E280C for ; Thu, 15 Feb 2018 13:02:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by perth.hirmke.de (Postfix) with ESMTP id 54AE286226C for ; Thu, 15 Feb 2018 13:02:43 +0100 (CET) X-Spam-Score: -2.9 Received: from perth.hirmke.de ([127.0.0.1]) by localhost (perth.hirmke.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BMq5YRtV_wm6 for ; Thu, 15 Feb 2018 13:02:42 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by perth.hirmke.de (Postfix) with ESMTP id 88E6786223C for ; Thu, 15 Feb 2018 13:02:42 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id 78DEEA80464; Thu, 15 Feb 2018 13:02:42 +0100 (CET) Date: Thu, 15 Feb 2018 12:02:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Regression for OCaml introduced by rebase 4.4.4 Message-ID: <20180215120242.GJ30794@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <000001d3a0d2$9f604860$de20d920$@cl.cam.ac.uk> <20180208151549.GA32555@calimero.vinschen.de> <20180209114048.GK30794@calimero.vinschen.de> <20180209171100.GM30794@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="reSNjdE3Iylkp4B8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2018-02/txt/msg00171.txt.bz2 --reSNjdE3Iylkp4B8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3352 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 > >=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" Content-length: 833 -----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--