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.
Thanks
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
