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 01:54:07 -0700
> 
> 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.

Can you elaborate about the other ways you had in mind?

> >> Sure, but that's true of any dumping method.
> >
> > Writing out the dumped data is almost trivial
> 
> Not really. Not nowadays.

Again, please elaborate.

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

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

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

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

A typical non-trivial Emacs session takes several seconds, sometimes
25 or more, to start, so I don't think the un-dumping that needs to
read the data will be significant.  (Isn't that more or less what
XEmacs did with their "portable dumper"?)

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

They are up to it today, but they are not meant for it.  Their
developers could easily decide that these jobs don't need to be
supported, and then we will be in the same situation as we are today
vis-à-vis the glibc development.

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

By the time you read the dumped data into Emacs, the randomization
will have been done already, so 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,
the fixup should be trivial, once you have a way of finding all the
pointers which need that.

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

But they won't!  They develop compilers and linkers, not tools to
undump Emacs.  Our specific use of their tools is not in their
projects' goals.

We once thought that Emacs is important enough for the Free Software
libraries to tweak themselves to accommodate us.  We were proven
wrong.  (AFAIK, only one Free Software library took that seriously,
and does that to this day.)  I see no reason to believe we will never
bump into similar problems by using tools whose main job is something
else.