bug#23529: Request for fixing randomize_va_space build issues

[Eli Zaretskii]

> Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 10 Sep 2016 16:01:28 -0700
> 
>     Conservative stack marking is for Lisp objects held in variables on
>     the stack.  Those objects cannot be relevant to dumping
> 
> Yes, but the conservativeness of the marking phase means Emacs cannot 
> relocate objects.

I don't understand how this is relevant.  What do you mean by
"relocating objects", and why would we need to do that as part of
un-dumping?

>     If mainline libc allows such control on its memory
>     allocation back-end, it is better to use that than rely on our own
>     replacement allocator.
> 
> Although that might be better than what we're doing, better yet would be to 
> not fiddle with such internal details of malloc at all.

Yes, and it's better not to fiddle with Emacs at all, if all we want
is simple C programs.

>     What about disabling randomization for the temacs run?
> 
> That is yet another low-level thing to configure, and to get right in new 
> ports.

We already have that in Emacs, don't we?

> The approach I'm suggesting does not rely on disabling randomization.

It has other costs, though.  A tradeoff should consider them all, not
one by one.

> This point is a tangent to its containing thread, as the thread in question 
> is about whether compilers and linkers can relocate pointers for us. The code 
> example establishes that compilers and linkers can do so, regardless of 
> whether Emacs is using that capability now. 

No, this point started with me saying dumping and reading dumped data
with fixups is relatively easy, and you objecting saying address
randomizations will defeat that.  Now we agree that it's a tangential
issue unrelated to my proposal.