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:from:to:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=default; b=VLpUl+2xZFV8xV80Aq4rChZJA9gIt fenut2xkW+HdZX+L1m3hFk6p9mlVC2WJATYMLBeKmZ8dFyRz/Zl8O1LGQxGh1Jqs xOPhvCUW3PUqrel84aIcNN5KG9Jl6GWEz9B8EyFsDwCTqvRa1HtG3ArAn+Pg4hlL HBhcEYHK2k6rnY= 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:from:to:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; s=default; bh=fqDre2V9vXXbtfTKs6lRU4/AhRU=; b=rzU +iQ+kFneKp5V4SElqV9mH7MXCL8rCAsxfr/v5cSRroaJY6Zy7rEfbM4htZj27UID N4E+XDj3QES6PknmuHnBrC5vJj/KXnVvtxto9LM3t1Vhxdv0wVwSUuiaPIDSiSD3 kSujggaCqi0ekJeSQ9lQqfNOfpYFDZQPBNk8loCA= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*M:local, Hx-spam-relays-external:sk:mail.au, H*RU:sk:mail.au, reserved X-HELO: outmail148107.authsmtp.com From: David Allsopp To: "cygwin AT cygwin DOT com" Subject: RE: Regression for OCaml introduced by rebase 4.4.4 Date: Fri, 9 Feb 2018 13:19:35 +0000 Message-ID: References: <000001d3a0d2$9f604860$de20d920$@cl.cam.ac.uk> <20180208151549 DOT GA32555 AT calimero DOT vinschen DOT de> <20180209114048 DOT GK30794 AT calimero DOT vinschen DOT de> <20180209131141 DOT GL30794 AT calimero DOT vinschen DOT de> In-Reply-To: <20180209131141.GL30794@calimero.vinschen.de> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Server-Quench: e0cd1820-0d9b-11e8-9f3b-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZ5RRob BmUtCCtbTh09DhZI RxQKKE1TKxwUVhJa I0lFL1x7O0wTWlBf HTVUBhpUWUIHDDFq aQpQZRVcYUBPVg9p VwZLQ1FMFQVtHx4A BAAfUx1tdQBZeTA3 ZE8WJCEiAUR/dEZ/ RwBRFmoHKzJgOzQe WEJYagMAeVFXfx4Q Yk12AnBffGxUNHxl QwU5ZW1pYSNlBXYd eAwCN18JWkcMGHYy QApKOh4mGElNRiMv NRsqN1UREA4bIw0o PFEoQl9Qb1lOTFE2 X-Authentic-SMTP: 61633634383431.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 213.105.212.114/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id w19DJoIP014888 Corinna Vinschen wrote: > On Feb 9 12:40, Corinna Vinschen wrote: > > On Feb 9 11:29, David Allsopp wrote: > > > > 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. > > > > > > 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. > > > [...] > > > 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. > > > > 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. > > ...and you must not use the 0x0:80000000 - 0x1:00000000 area because > that's reserved for thread stacks. > > To clarify, the full layout requirements: > > - 0x0:00000000 - 0x0:80000000 Windows > - 0x0:80000000 - 0x1:00000000 Cygwin pthreads (including main thread) > - 0x1:00000000 - 0x1:80000000 Executable > - 0x1:80000000 - 0x2:00000000 Cygwin DLL > - 0x2:00000000 - 0x4:00000000 Rebased DLLs > - 0x4:00000000 - 0x6:00000000 Non-rebased DLLs (hashed default > addresses > generated by binutils ld with > -auto-image-based (default on Cygwin)) > - 0x6:00000000 Start Address Heap, growing upwards > - 0x8:00000000 - 0x700:00000000 Mmaps, allocated downwards > - 0x700:00000000 and beyond Windows Thanks for this (and your time on this question generally!). I reckon that the jump tables will sort this and we'll be able to stop doing horrible things with --image-base completely, which should mean that flexlink (and therefore OCaml too) will start properly respecting the Cygwin address space layout! It's a shame that the layout means that the trampolines would always be needed, but I very much doubt their overhead will be significant in any program. David -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple