DLL loading

[Corinna Vinschen]

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:

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

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

- Stop linking against Cygwin DLLs other than the Cygwin DLL itself.
  Instead, provide our own loader.

Does anybody feel an affinity to have a look into one of the above?
Or, does anybody have another idea how to ease the pain?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat