bug#23529: Request for fixing randomize_va_space build issues

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 12 Sep 2016 06:09:10 +0000
> 
>     > Isn't it the other way around: the first priority is to enable
>     > randomization and all the other modern techniques for running the
>     > dumped Emacs?
> 
>     I think we want to be able to build the full Emacs in a container; that is without needing, at any point in the process, to disable randomization.  If I understand correctly, this means that even the process of dumping Emacs cannot involve disabling randomization.
> 
> Yes, that's correct. No step in the build process should have to disable randomization.

Got it, thanks.

However, on second thought, I don't see why this would be an issue.
I've mentioned gmalloc as a candidate for an malloc implementation
during the temacs run (i.e. during dumping), because gmalloc can be
told to use our own sbrk, and that sbrk could allocate memory off an
array we define; this might make the job of finding the memory to dump
easier.  Paul said that gmalloc doesn't work well when ASLR is
enabled, but I now think this is not relevant, because we will be
allocating from a single contiguous array, which AFAIU is unaffected
by ASLR, and also makes those gmalloc problems a non-issue as a side
effect.

Moreover, if for some reason using gmalloc is not an option, or
doesn't really help with this job, that would just make the job of
collecting the memory to dump harder, but not too hard.  Again, ASLR
adds nothing to this picture, as the job of collecting the memory to
dump will be based on known pointers to known data structures, and the
values of the addresses where these pointers point to are of no
importance.