bug#23529: Request for fixing randomize_va_space build issues

[Eli Zaretskii <eliz@gnu.org>]

> 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 00:52:33 -0700
> 
> 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.

Conservative stack marking is for Lisp objects held in variables on
the stack.  Those objects cannot be relevant to dumping, because
stack-based variables disappear without a trace when we dump _today_,
and we don't have any problems with that.

GC cannot disregard stack-based values, without asking the programmer
to use GCPRO.

> > 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.

I agree.  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.

> > 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.

What about disabling randomization for the temacs run?

> > 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).

No, I don't think we do that in code that runs in temacs.  If you see
such code, which defines statically-allocated Lisp objects that need
to survive dumping, please point me to it.

In any case, even if such static Lisp objects exist, they just need to
be fixed as well, as part of un-dumping.

> The example demonstrates 
> that compilers and linkers can relocate tagged Lisp pointers themselves, which 
> means we don't have to do that ourselves.

You don't need to convince me that a linker can relocate addresses, I
know that.  Our differences of opinions are not about that.

> > 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.

I don't see why we would want to, it would mean too many
disadvantages.  But even if we did, it just means separate fixup value
for each block, that's all.