This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] an alternative to rebasing

I may have found a way of getting cygwin fork() to load dlls reliably
without the need for rebasing dlls.

I described my understanding of the problem in a previous post
(, but basically it
boils down to the fact that during fork() the child process does not
load dlls in the same order as the parent, and consequently cannot
always get them to the same address. I would be difficult to record and
reproduce the full sequence of LoadLibrary/FreeLibrary calls, but after
some experimentation I believe that there is an alternative. If the
child loads dlls in the order that they are in memory in the parent,
then it appears to get the correct addresses. To test this I patched
cygwin1.dll so that a list of loaded dlls, in address order, is
maintained, and the child walks this list instead of the existing list
of all dlls.

I have done some simple tests that fail with cygwin1.dll-1.3.12-2, but
succeed with my patched dll. I am also running the gnome desktop and
core apps which depend on run-time loaded dlls to function and that is
OK. I would like package maintainers who would otherwise need rebasing 
(Jason?) to try my patch and report results here if they can find time.

If this approach proves successful, then rebasing would still improve
load time for dlls, but apps using run-time loading of dlls would no
longer depend on rebase to function. 

Attached is the patch and a Changelog entry


Attachment: mypatch
Description: Binary data

Attachment: cygwin_changelog
Description: Binary data

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]