[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: Tue, 6 Sep 2016 13:37:20 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 09/06/2016 12:18 PM, Eli Zaretskii wrote:
Then users on those platforms will never be able to re-dump.

True. But they'll still be better off than they are now, since they can't dump at all now. Plus, for extra credit we could dynamically link the dumped object modules at Emacs startup, with the idea of making it practical to re-dump.

I actually don't understand why the data should be serialized as C
code.  Why not just data that is read into memory (with conversion to
the native format)?  A compiler is not the only way to convert text
into binary data.

The compiler-based approach should be simpler and more portable than messing with low-level binary I/O. For example, it should be easy to arrange for some of the objects to be read-only: just declare them to be 'const'. Another example: on hardened platforms with PIEs (position-independent executables), you get a PIE for free as the dumped executable, instead of having to disable PIE as we do now.

Although Emacs can do this sort of work itself (e.g., randomizing locations of dumped objects, munging pointers as they come in to match the random locations, and using mmap to make the relevant objects const), it should be better for Emacs to use the linking technology already available on modern platforms, rather than trying to reinvent the wheel.

reply via email to

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