bug#23529: Request for fixing randomize_va_space build issues

[Paul Eggert <eggert@cs.ucla.edu>]

On 09/06/2016 12:18 PM, Eli Zaretskii wrote:
> Then users on those platforms will never be able to re-dump.

True. But they'll still be better off than they are now, since they 
can't dump at all now. Plus, for extra credit we could dynamically link 
the dumped object modules at Emacs startup, with the idea of making it 
practical to re-dump.

> I actually don't understand why the data should be serialized as C
> code.  Why not just data that is read into memory (with conversion to
> the native format)?  A compiler is not the only way to convert text
> into binary data.

The compiler-based approach should be simpler and more portable than 
messing with low-level binary I/O. For example, it should be easy to 
arrange for some of the objects to be read-only: just declare them to be 
'const'. Another example: on hardened platforms with PIEs 
(position-independent executables), you get a PIE for free as the dumped 
executable, instead of having to disable PIE as we do now.

Although Emacs can do this sort of work itself (e.g., randomizing 
locations of dumped objects, munging pointers as they come in to match 
the random locations, and using mmap to make the relevant objects 
const), it should be better for Emacs to use the linking technology 
already available on modern platforms, rather than trying to reinvent 
the wheel.