From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126839 invoked by alias); 9 Feb 2018 11:40:56 -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 126830 invoked by uid 89); 9 Feb 2018 11:40:56 -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 11:40:53 +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 45F52721E280C for ; Fri, 9 Feb 2018 12:40:49 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id C49C05E031C for ; Fri, 9 Feb 2018 12:40:48 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id B26C8A80865; Fri, 9 Feb 2018 12:40:48 +0100 (CET) Date: Fri, 09 Feb 2018 11:40:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Regression for OCaml introduced by rebase 4.4.4 Message-ID: <20180209114048.GK30794@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ULyIDA2m8JTe+TiX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2018-02/txt/msg00096.txt.bz2 --ULyIDA2m8JTe+TiX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3892 On Feb 9 11:29, David Allsopp wrote: > Corinna Vinschen wrote: > > On Feb 8 11:47, David Allsopp wrote: > > > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the > > > 0x200000000 base address requirement added in rebase 4.4.4. Possible > > > fixes for this at the bottom. > > > [...] > > > $ ocaml > > > OCaml version 4.04.2 > > > > > > # #load "unix.cma";; > > > Cannot load required shared library dllunix. > > > Reason: /usr/lib/ocaml/stublibs/dllunix.so: flexdll error: cannot > > > relocate RELOC_REL32, target is too far: 0xfffffffc013d8b5f > > 0x13d8b5f. > > > > > > This is a known problem and fundamental limitation of flexdll (there > > > is no > > > RELOC_REL64 in COFF). > >=20 > > 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 this. > > To me this looks like a bug in FlexDLL, not a requirement to let certain > > 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. >=20 > FlexDLL is "solving" the problem of allowing a dynamically loaded > library to refer to symbols in the main application (or in previously > dynamically loaded libraries, without loading them a second time, as > the Windows loader I believe does). FlexDLL does this by deferring > COFF relocations to runtime and it achieves that by sitting in front > of both the linker when the DLL is constructed and also an > application's main (or dllmain). For normal linking, since PE limits > code size to 2GB, there is no need for a RELOC_REL64 relocation type. > However, because we're actually resolving the symbols dynamically, on > 64-bit the DLL may have been loaded too far from the executable (or > other DLL) image it's resolving to (for actual Windows resolution to > DLL symbols, you'd be using the stub code generated either by the > linker or by __declspec(dllimport), which would similarly be > guaranteed to be within the range of RELOC_REL32 because the stub > itself is static). >=20 > 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. >=20 > 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. Two points: - 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. - 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. I'm curious why this isn't done yet. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --ULyIDA2m8JTe+TiX Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp9iMAACgkQ9TYGna5E T6BwgBAAnjs/x+ti2RSrry14biXppg/JHmusO4xMGpqAk7fCXctxK1S//NnyRz0K tNzkgM0pXF0PrSoV8CxeD+ejOD6lQ9MZpyAfgk4BnORZudcxtoAhm8kUiwFrdJBC rL3fVMEK3oeJx4hVpSd4IWQrKW1wSQwH+HtftxBRr080OqlSnYJ8TlBCkvaurOy+ d1A1xdgtiMvpEx7UctTw0hJ6EhukR8QX0CWOZhQDPuCV6AWyS0JLIVzJojtzvWnE l+c4UROBHrJ5XMvX6/njwkuTUntef8sgtYbP6m2adQpioUwHUjWxCQvUfE4jXZ3b ManF8gH+s1G5cQjb+k4ioCmckQo6KwJu47GoJjDkBJ2QbyzXZKVvDC+lnuH9Rqaz gvR1q68caXofogWmEPmMdm07tvmnwkjN5hSAdGV03g2nJtduRdOWGqF9kYWaIcUf ABUOwL4grKJ1F/oSzZ9Y+XoPNrksgSTiH+iv9QlJ6QR5G5NAk6VWRhtk7IQmz81u 9Nm3rwtt8GX75l9evkHYMSMGQ2fc+Jovj1w3cSp3/4AqYzqHrYM9XP+V3V0ndT8e encL2UbVnA5a75EX9STp+oN/81ukL3khruoF+gwplkTDGGcvczoJY5nXdnrk0R+8 RQqzVoDiHDaKkzRHG0E+9AIwWaOuZiL4S0FXaqS6oEIJKqPhAj0= =gU5Z -----END PGP SIGNATURE----- --ULyIDA2m8JTe+TiX--