[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.
- bug#23529: Request for fixing randomize_va_space build issues, (continued)
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/07
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/09
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/10
- bug#23529: Request for fixing randomize_va_space build issues,
Paul Eggert <=
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/10
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/10
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/11
- bug#23529: Request for fixing randomize_va_space build issues, Paul Eggert, 2016/09/11
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/11
- bug#23529: Request for fixing randomize_va_space build issues, Philippe Vaucher, 2016/09/11
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/11
- bug#23529: Request for fixing randomize_va_space build issues, Clément Pit--Claudel, 2016/09/11
- bug#23529: Request for fixing randomize_va_space build issues, Philipp Stephani, 2016/09/12
- bug#23529: Request for fixing randomize_va_space build issues, Eli Zaretskii, 2016/09/12