Re: Regression for OCaml introduced by rebase 4.4.4

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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

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
> > > 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.
> > >
> > > 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.
> 
> Our executables are also compiled via flexdll's flexlink which sets
> --image-base in its call to the linker. I don't think the Cygwin DLL
> does anything which alters that, right?

It doesn't.  It can't, actually.  But you're breaking assumptions Cygwin
is relying on under the limitations Windows has.

> Another "fix" I tried while
> investigating was to change the --image-base we specified to be within
> 2GB of where rebase has put the DLLs, which also worked.
> 
> > - 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.
> 
> That was what our head-scratching has arrived at too, which I'm in the
> process of doing.

\o/

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


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