[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23529: Request for fixing randomize_va_space build issues

From: Paul Eggert
Subject: bug#23529: Request for fixing randomize_va_space build issues
Date: Sat, 10 Sep 2016 00:52:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]