|
From: | Paul Eggert |
Subject: | bug#23529: Request for fixing randomize_va_space build issues |
Date: | Fri, 9 Sep 2016 01:54:07 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 |
Eli Zaretskii wrote:
Lisp objects are referenced through the obarray
Sure, but they are also referenced in many other ways. The obarray is just one corner of this.
Sure, but that's true of any dumping method.Writing out the dumped data is almost trivial
Not really. Not nowadays.
The advantage of dumping to C code is that the compiler and linker will deserialize it for you.That's true, but I think you pay much more in the serialization phase.
That's fine. Serialization is rare, typically just when Emacs is built. Deserialization is much more common, typically whenever Emacs starts up. So it can be a win to speed up and simplify deserialization at the expense of serialization.
the compiler and the linker were not meant for these jobs
I don't see why today's compilers and linkers wouldn't be up to these jobs. Emacs is not that large by today's standards. The proof of that will be in the pudding, no?
writing the dumped data and then reading it with fixups is something we can do ourselves without relying on any external technologies which need to be bent to our needs.
I don't think so. We need to rely on and/or work around properties of address randomization which will be platform-dependent. It will be tempting to do the job poorly, and lose any reliability and/or security benefits of randomization that we might otherwise get for free. Letting the compiler and linker do this work for us will save us work in the long run.
As the number of people who are able to futz with Emacs internals at this depth continues to dwindle,
This is exactly why we should let the compiler- and linker-writers do this work for us.
[Prev in Thread] | Current Thread | [Next in Thread] |