RE: Regression for OCaml introduced by rebase 4.4.4
- Date: Fri, 9 Feb 2018 13:19:35 +0000
- From: David Allsopp <David.Allsopp@xxxxxxxxxxxx>
- Subject: RE: Regression for OCaml introduced by rebase 4.4.4
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
> > >
> > > 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
> > 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
> 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.