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=StKp/motEaQ5AHHLNXKazlhLSXh3w
	NxN6aen3Mv+0oO3E/fuhz+PtvpwSF/qeSyf5i40iDU2YqMsCJzCoJwCDQSxTUn9U
	zQR3n6ZVWhOKM3pNDhVA1dAD7am19ySpXxXFcI7EPJ/OYCAlh4z3WdV8/9UWZN8w
	V6fR89Z4BbJUxU=
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=e7olwvfKvhWm2/3Hp2icwJpFaG0=; b=FZq
	p60Ly8WnIachVc//+XskChckcI93mHTJSliRNXKVwtIHernmMSDURxHfHJqkMdB4
	csjjk+nqopO51T9+2aQNB6MKJz5zc4t9LFO4l7Lz87uHIRwEBffHJstLpjRsIAoB
	7/+hKvx7Ragnk4nS73jls07LJijJLaYCdjxJQRJg=
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=-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=sins, unsurprisingly, our, H*M:local
X-HELO: outmail148101.authsmtp.com
From: David Allsopp <David DOT Allsopp AT cl DOT cam DOT ac DOT uk>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: Regression for OCaml introduced by rebase 4.4.4
Date: Thu, 15 Feb 2018 11:44:50 +0000
Message-ID: <E51C5B015DBD1348A1D85763337FB6D90189AA34DC@Remus.metastack.local>
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>
In-Reply-To: <20180209171100.GM30794@calimero.vinschen.de>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-Server-Quench: a374ddb9-1245-11e8-9f3b-9cb654bb2504
X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse
X-AuthRoute: OCd1ZAARAlZ5RRob BmUtCCtbTh09DhZI RxQKKE1TKxwUVhJa I0lFL1x7O0wTWlBf HTVUBhpVVUIHDDFq aQpQZRVcY0BKWw9v UwZLQ1FMFQVtHx4A BAAfUx1tdQBZeTA3 ZDAQBzEGOER6dER4 RgBQE2wPKzZjb2RL BBJRagJWdAZXfx4Q 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 w1FBj9Z5032230

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

<snip>

> > > 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).
> 
> 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=medium, IIRC.

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.

gcc -Q --help=target 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=small 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!

Is it the case with -mcmodel=medium 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=32 and -mcmodel=medium really is?


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