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