[haiku-commits] Re: haiku: hrev46460 - src/system/kernel/vm

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 01 Dec 2013 17:53:24 +0100

On 12/01/2013 04:29 PM, Pawel Dziepak wrote:

2013/12/1  <ingo_weinhold@xxxxxx>:

84ed99c: mmap(): Fix !MAP_FIXED with non-NULL address case

   In that case the caller ideally wants to obtain an allocation at the
   specified address, which was thwarted by using
   B_RANDOMIZED_BASE_ADDRESS. Use B_BASE_ADDRESS instead.
   This improves the experience with the gcc 4 pre-compiled headers
   implementation (which expects to be able to map the PCH file at the same
   address where it was located originally when it had been created), but
   doesn't fix it completely. As long as ASLR is active, it is always
   possible that something else (mapped shared objects, heap, stack) is in
   the way.


Is this necessary? As you mentioned, it is still possible that gcc
won't be able to map the PCH file at the location it was generated.
Only disabling ASLR for gcc guarantees pre-compiled headers to work
properly (apart from implementing support for ASLR in gcc but it seems
nobody is interested in doing that). Basically, this patch weakens
ASLR, but is not a complete solution to any problem.
It may not help with gcc's PCH implementation, but it simply is the way mmap() should work -- not mandated by POSIX, but apparently as implemented by other systems (on Linux also with ASLR enabled). The whole point of passing a non-NULL address is to get that address, if possible.
Obviously gcc's PCH implementation is broken in that it actually requires to get that address. But, if, as a fallback when not getting that address, it would adjust the mapped data to the new location, it would be a perfect example of a use case for that mmap() feature -- a possible optimization.
Another use case would be, when an algorithm could benefit from the new allocation adjoining a previous one, e.g. so that it could just resize an existing data structure instead of falling back to a less efficient alternative. 

CU, Ingo

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 12-2013