Observation for ALL maintainers who provide dlls (was Re:question for perl maintainer)

[Brian Dessent]

"Pierre A. Humblet" wrote:

> The attached script takes the name of a .exe or .dll,
> uses cygcheck to find the dll dependence and checks for conflicts.
> 
> This will allow you to check your favorite applications or dlls,
> seeing if --enable-auto-image-base works for you.

I was under the impression that relocations at startup-time (i.e. all
DLL base addresses set to 0x10000000) was fine and doesn't cause the
remap issue, since the windows loader apparently will always choose the
same layout for the DLLs for a given .exe every time.  But runtime
dynamic linking (dlopen / LoadLibrary) causes there to be variability as
to where in the memory space the module will be mapped (if it needs to
be relocated that is), and thus the problem on fork, and the reason why
it tends to only affect things like apache and perl modules.  Is this a
correct view of what's going on?  Wouldn't this tool really need to be
aware of runtime module loading to be effective?

Note: We should probably figure out how to get the ImageBase-hashing
working regardless, because as I understand it there's a performance hit
when a DLL must be relocated.  If I understand correctly this causes
both a startup hit as the loader has to remap all the addresses, as well
as a runtime hit because it has to make all the text pages writeable and
it can't share pages of common libraries.  (Too bad Windows doesn't do
PIC / GOT / PLT so that the text pages can remain readonly.)

Brian