RE: Regression for OCaml introduced by rebase 4.4.4

[David Allsopp <David.Allsopp@cl.cam.ac.uk>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3172 bytes --]

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
\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ