public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Regression for OCaml introduced by rebase 4.4.4
Date: Thu, 15 Feb 2018 12:02:00 -0000	[thread overview]
Message-ID: <20180215120242.GJ30794@calimero.vinschen.de> (raw)
In-Reply-To: <E51C5B015DBD1348A1D85763337FB6D90189AA34DC@Remus.metastack.local>

[-- Attachment #1: Type: text/plain, Size: 3393 bytes --]

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
> 
> <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?

I don't know what cmodel=32 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2018-02-15 12:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08 11:47 David Allsopp
2018-02-08 15:04 ` Corinna Vinschen
2018-02-09 11:30   ` David Allsopp
2018-02-08 15:15 ` Corinna Vinschen
2018-02-09 11:30   ` David Allsopp
2018-02-09 11:40     ` Corinna Vinschen
2018-02-09 13:11       ` Corinna Vinschen
2018-02-09 13:19         ` David Allsopp
2018-02-09 13:13       ` David Allsopp
2018-02-09 17:11         ` Corinna Vinschen
2018-02-15 11:44           ` David Allsopp
2018-02-15 12:02             ` Corinna Vinschen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180215120242.GJ30794@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).