The gcc PCH implementation works by using mmap() to quickly resurrect the precompiled header when compiling on a new file.
To allow this to be done quickly, mmap() is used when creating the precompiled header and the precompiled information is relocated to the area returned by mmap(). When saving, mmap() is called like this:
mmi.preferred_base = mmap (NULL, mmi.size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fileno (state.f), mmi.offset);
When restoring the precompiled header, mmap() must return the same memory address, otherwise the scheme fails. When restoring, mmap() is called like this:
addr = mmap (mmi.preferred_base, mmi.size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fileno (f), mmi.offset);
The current implementation does not know anything about the Cygwin 64k granularity, and does not use MAP_FIXED because MAP_FIXED may have bad side-effects on other implementations.
My question relates to fhandler_diskfile::mmap() in mmap.cc. This method calls MapViewOfFileEx() to create the mapping like this:
void *base = MapViewofFileEx(h, access, high, low, len, (flags & MAP_FIXED) ? *addr : NULL);
In other words, the lpBaseAddress parameter is NULL (ie allow Win32 to choose) unless MAP_FIXED is used -- and gcc does not use MAP_FIXED.
Despite this, the two mmap() calls in gcc currently yield the same base address --- I suppose more by good fortune than anything else.
From the FreeBSD man page:
If addr is non-zero, it is used as a hint to the system. (As a convenience to the system, the actual address of the region may differ from the address supplied.) If addr is zero, an address will be selected by the system.
I'd like to suggest that the mmap() behaviour in this regard be changed to mimic the BSD mmap(). I think this is possible.
Are there other reasons why this shouldn't be done?
This would require changes to mmap64() because addr may not be aligned on the allocation granularity.
Earl
-- 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/