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]

mmap() and gcc precompiled headers

I've been trying to get the new gcc PCH code working on Cygwin.

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

   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,
	       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 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

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.


-- 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]