From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109185 invoked by alias); 9 Feb 2018 17:11:06 -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 109097 invoked by uid 89); 9 Feb 2018 17:11:06 -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; Fri, 09 Feb 2018 17:11:04 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 3412B721E281A for ; Fri, 9 Feb 2018 18:11:01 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id B6DB75E03A7 for ; Fri, 9 Feb 2018 18:11:00 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id A4770A80865; Fri, 9 Feb 2018 18:11:00 +0100 (CET) Date: Fri, 09 Feb 2018 17:11:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Regression for OCaml introduced by rebase 4.4.4 Message-ID: <20180209171100.GM30794@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WRT3RXLOp/bBMgTI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2018-02/txt/msg00100.txt.bz2 --WRT3RXLOp/bBMgTI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2927 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" Content-length: 833 -----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--