Regression for OCaml introduced by rebase 4.4.4

[Corinna Vinschen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20180215/4686e384/attachment.sig>