bug#23529: Request for fixing randomize_va_space build issues

[Eli Zaretskii]

> Cc: p.stephani2@gmail.com, philippe.vaucher@gmail.com, 23529@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 9 Sep 2016 09:16:39 -0700
> 
> 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.

All of those data structures are memory allocated for Lisp objects and
their supporting structures, with known structures, so we know exactly
which pointers need fixing.

> > 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!

gmalloc is already implemented.

If there are libc's out there that allow the application to define its
own sbrk, then we could use that (we do on Windows).  If not, gmalloc
will be good enough for the temacs run; emacs will of course use the
normal libc allocators.

> 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.

We will use libc in emacs.

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

Each one is a different tradeoff.

> > 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.

You have a small .emacs, I guess.

Anyway, even 1.2 sec is an eternity for the job at hand.  I don't see
a problem.

> > 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.

Yes, we used to think that back when unexec was implemented.

> > 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.

What is a "block" in this context?  Surely, a data structure with
linked pointers cannot be distributed between different "blocks",
since a linker will not know how to fixup each address, because it
doesn't understand the data structure.  So I think you are talking
about an issue that will not affect us.  If that's not so, please do
describe the details, please don't hide behind "easier to write the
code" argument, because this issue is IMO of the utmost importance for
the future of Emacs.

> Worse, you have to know where the pointers are.

We know.

> > 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 won't be able to use them as just compilers and linkers.  We will
be using them for a job that is quite a bit more complex and
different.