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: Wed, 7 Sep 2016 13:12:27 -0700
> 
> On 09/07/2016 11:11 AM, Eli Zaretskii wrote:
> > Data that has to be dumped and loaded are accessed through pointers
> 
> Sure, but the data contains pointers to other data

I guess you mean the 'previous' and 'next' pointers?  Fixing that is
just a simple job of adding a fixed offset to each such pointer.

> (and perhaps to code? I haven't checked)

defsubr does that, but fixing the address of the function after
loading the dumped data is also very simple: for each defsubr, rewrite
its function pointer.

> > We'd need to plug the compiled data into
> > data structures that support the Lisp interpreter, something which the
> > compiler and linker won't help us.
> 
> Ah, but they can! Because Emacs now assumes the LSB representation, 
> Emacs objects now encapsulate pointers simply by adding a constant to 
> them. All C compilers and linkers support that, even for addresses 
> defined by other compilation units.

First, Emacs doesn't assume LSB representation when built with wide
ints.  And second, I think you forget the part of the task that with
your proposed method is required to "serialize" the dumped data as C
code.  AFAIU, you are talking about writing and debugging an entirely
new back-end to all the DEFSYM, DEFVAR, defsubr, etc. stuff we use
during dumping, and in addition some new code that would either
replace lisp_malloc and friends during dumping, to produce C code, or
something that would traverse the Lisp data as part of the new
implementation of unexec and convert the Lisp data into C code.  That
is a formidable job in itself, which I think is much more complex than
data I/O and the necessary fixups.