This is the mail archive of the cygwin 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]

Re: Question of the necessity of rebaseall

On 2009-5-14 9:34, Larry Hall (Cygwin) wrote:
Lenik wrote:
On 2009-5-14 8:55, Larry Hall (Cygwin) wrote:
Lenik wrote:
Imagebase in PE header is something a bit of optional, that means if
two dlls with same imagebase, the OS kernel will automaticly relocate
one of them, to put them in different virtual spaces. So, rebase
should be a utility for optimizing the overall start-up speed, to
reduce avoidable relocations, rather then fix start-up errors.

Any idea?

cygwin1.dll cannot be relocated if the fork semantics are to work. So while what you say above is true for apps in general, it's not true for Cygwin apps.

I can't figure out how fork will break the relocation, for libraries have been loaded, they're already relocated before invoke into fork, and for libraries haven't been loaded, they don't need to share memory after new processes created by fork.

You have it backwards. Forking doesn't break the relocation. Relocation breaks forking. cygwin1.dll needs to have a very special memory layout to implement the fork semantics in Win32. If this memory layout is disrupted, fork breaks. Relocating cygwin1.dll disrupts the required memory layout. 'rebaseall' does its best to locate all Cygwin DLLs that it knows of into a layout that avoids collisions. This maintains the required memory layout so fork can do its job.

Could you explain in more detail? I can't find any document about this special memory layout.


-- Unsubscribe info: Problem reports: Documentation: FAQ:

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