bug#23529: Request for fixing randomize_va_space build issues

[Paul Eggert <eggert@cs.ucla.edu>]

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.