This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont


> That means user space has to keep track mmap/mremap/munmap.
> It isn't going to work.

By default nothing is put into the first 4GB other than the main
executable. All mmaps without special flags or arguments end up
high up in the address space by the default mmap placement policy.

So the only thing you're normally competing with in the first 4GB
is your own (special) mappings and the main executable.

If you make some reasonable assumptions about the load address and size
of the executable you can guess likely free ranges.

Then just pick a random address in those and try to mmap it with
the mmap hint. If if fails fall back to the full 4GB (or try again a
few times)

It shouldn't be that hard to implement. One minor issue would
be that ASLR would cause even more variability than usual because
it adds penalty in rare situations (if there is a collision
that forces a library to be >4GB)

-Andi


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