bug#23529: Request for fixing randomize_va_space build issues

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

Eli Zaretskii wrote:

> I fail to see why it would be hard to maintain that portably.  Those
> data structures are entirely our design and implementatio

If it were *that* easy to do, the garbage collector would be doing it. It does 
not. It uses conservative collection, which is easier as it does not relocate 
pointers.

> temacs is not a program that needs to run for prolonged time
> intervals, its only purpose is to produce the data that the un-dumped
> Emacs will use.  So whether its malloc implementation is strong enough
> by today's standards is not a relevant question.  What matters is is
> it good enough for what temacs should do before it exits.

Fair enough. Still this hybrid-implementation approach, where the code uses one 
malloc implementation before dumping, and a different one after, is an extra 
complexity that makes it harder to understand and maintain Emacs. It would be 
better to remove this hack, and we should not be piling even more gingerbread 
atop it.

> we could have a variable that would force using the
> pre-dump malloc in emacs.

That would be still more complexity and state.

>> Plus, it assumes sbrk, which is backward-looking.
>
> What part assumes sbrk?

The current gmalloc implementation assumes the sbrk model, and operates poorly 
(if at all) when the underlying implementation uses address randomization. We 
are already at the edge of portability here; the fact that it works at all on 
modern GNU/Linux is a bit of an accident, requires mysterious tweaks 
occasionally at the C level, and there's no guarantee it will continue to work.

> we can still implement undump using a data
> file, but it will make our job slightly more complex, as we'd need to
> collect the data allocated off the heap before dumping it.  Not rocket
> science, either.

None of this is rocket science! But it is unnecessary complexity.

> But we don't do these things in our code, so how is this relevant to
> this discussion?

We do almost all of that example in our code already. Most of the example was 
taken from lisp.h (with some simplifications just for the example; the actual 
implementation would be based on the current lisp.h). The example demonstrates 
that compilers and linkers can relocate tagged Lisp pointers themselves, which 
means we don't have to do that ourselves.

> One example is string_blocks, which we
> use to maintain Lisp strings.  Surely, this structure will be in a
> single "block" under memory randomization, right?

That would be simpler, at least at first. But it's not the only possibility. For 
example, we could put each pure string in a separate block.