bug#23529: Request for fixing randomize_va_space build issues

[Paul Eggert]

On 09/09/2016 02:09 AM, Eli Zaretskii wrote:
> Can you elaborate about the other ways you had in mind?

The best way to elaborate this is to write code. That being said, there 
are a lot of pointers in the data structures of (e.g.) alloc.c and they 
need to be saved and restored and demangled in the process.

> What I had in mind is just a single 'write' (resp. 'read') call for
> any contiguous region of memory.  (For best results, we will probably
> want to use gmalloc so that it allocates memory off a single array we
> define, so that we have fewer regions to write and read.)

That is exactly the wrong way to go. We should not implement our own low 
level memory allocator again! Memory allocation is getting fancier and 
fancier internally in glibc and in other C libraries, for both 
performance and security/robustness reasons, and we shouldn't be wasting 
our development resources trying to keep up.


> By "pay" I meant the development, debugging, and maintenance costs,
> not the run-time costs.

I meant both.

> A typical non-trivial Emacs session takes several seconds, sometimes
> 25 or more, to start

?!  That may be typical for *you*. It is not typical for me. On the 
six-year-old desktop at work that I'm using to type this message (hard 
disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to 
start up. Even 1.2 seconds is too long, as I start up Emacs a lot.

> Their
> developers could easily decide that these jobs don't need to be
> supported

That's not likely. C compilers are commonly used as back ends for other 
systems. Compiler writers take that part of the job seriously.

> all you need is to fixup the pointers
> in the dumped data accordingly.  Since the final effect of the
> randomization is just to change the addresses by some fixed amount,
No, every block is put into a random location. Otherwise it's not 
random. So different values need to be added to different pointers. 
Worse, you have to know where the pointers are.

> They develop compilers and linkers, not tools to
> undump Emacs.

And as long as we use them as compilers and linkers, we will be fine. We 
got into the current mess because we went under the covers of the 
underlying systems. That was reasonable in the 1980s when things were 
simpler, but it is not reasonable now.