DLL loading

[Christopher Faylor]

On Sun, May 22, 2011 at 03:27:05PM +0200, Corinna Vinschen wrote:
>On May 17 11:53, Ryan Johnson wrote:
>> On 17/05/2011 11:32 AM, Corinna Vinschen wrote:
>> >On May 17 07:12, Ryan Johnson wrote:
>> >>On 17/05/2011 4:19 AM, Corinna Vinschen wrote:
>> >>>What I'm observing is that even big apps like vim, emacs, octave don't
>> >>>use addresses beyond 0x03000000.  Setting the heap to an address of
>> >>>0x20000000 appears to be a rather big waste of memory.
>> >>>
>> >>>So I'm planning to drop the bar to 0x08000000, which gives the heap
>> >>>a potential extra memory of 384 Megs. and still leaves a confortable
>> >>>cushion of 80 Megs for the OS.
>> >>On my machine, running 'emacs-X11 -nw', quite a bit of stuff appears
>> >>at 0x01????? (showing only allocation bases below for brevity):
>> >>>[...]
>> >>Another bunch appears in the 0x19??????-0x1C?????? range (again,
>> >>allocation bases only):
>> >>>19A80000-19C7B000 ---p 00000000 0000:0000 0
>> >That's kind of annoying.  I wouldn't have believed that the OS DLLs
>> >would take so much memory.  I'll stick to 0x20000000 for now.
>> annoying++
>
>I'm still puzzled.  I used W7 32 bit and 2008 R2 64 bit for testing, and
>even using really big apps like emacs-x11, xemacs, or the X server, I
>can't reproduce that the OS uses memory beyond 0x04000000, on both
>systems.  Are you sure that rebasing wouldn't fix this?
>
>Along these lines there's another problem.
>
>Apart from the fact that some of our Cygwin distro DLLs are still not
>auto-based (the DLLs from libopenldap2_3_0-2.3.43-1, for instance),
>what's really annoying is that Cygwin distro DLLs which have to be
>rebased on the fly due to collisions with other Cygwin DLLs are rebased
>to memory below 0x04000000, too.  Rebasing helps a lot, but there's
>probably no way to avoid this entirely.  That's really bad.
>
>Yes, we can't use a native fork mechanism, so we have to find another
>way.  Three ideas come to mind:
>
>1 A more intelligent algorithm in rebase/rebaseall to place the various
>  Cygwin distro DLLs so that they don't collide, perhaps together with a
>  postinstall script which rebases automatically.  This is a short-term
>  way to deal with the problem.
>
>2 Figure out if and how we can hook the Windows loader so that rebasing
>  a DLL on the fly at load time can be influenced in terms of the start
>  address.
>
>3 Stop linking against Cygwin DLLs other than the Cygwin DLL itself.
>  Instead, provide our own loader.

I think 1. and 2. are the only feasible ways to deal with the problem.  
For 3, maybe we could port ld.so.

I've already asked for a more intelligent rebase/rebaseall in the cygwin
list but there wasn't much of a response.  It's a short-term solution
but I think it would eliminate a lot of problems.

cgf