Re: Dumper problems and a possible solutions

[Stefan Monnier <monnier@iro.umontreal.ca>]

> To solve ALL of the problems with the dumper (which seems to be a
> recurring theme), I have a proposed design to make it fully portable
> -- even moreso than xemacs "portable dumper" which is still an ugly
> hack. The idea is simple: after loading all of the lisp objects that
> need dumping, walk the lisp heap and output a representation for each
> object as a giant static array in C source format, then compile and
> link this new translation unit with the rest of the emacs .o files to
> produce a final emacs binary. No hacks with binary formats would be
> involved; everything would happen at the C source level. As part of
> the lisp heap dumping, address references to other objects would have
> to be relocated to refer to the object's position in the static array
> rather than the original address at which the object resided when
> created in temacs. That's some non-trivial work, but definitely no
> prohibitive, and as a bonus, the generated address-constant references
> in the static array would transform to load-address-relative
> relocations for the linker, allowing emacs to be built as a
> position-indepdendent executable (PIE) if desired.

Generating a big static C array against which to link sounds fine and
very portable, indeed.  I'm not sure how hard/easy the relocation could
turn out to be.  There's the problem of finding *all* the references,
and there's the problem that moving an object means that its "hash"
value changes.

> If not, or if that's going to be a very long-term project, would a
> cleaned-up version of my current solution be acceptable upstream?

Making the "dump" portable would be very welcome.  Generating a big
static C array sounds OK.  So whether the result is acceptable or not
will depend on what's needed to solve the problems linked to relocation.

Another option is to "dump" the heap into a binary file that we would
later on "mmap".


        Stefan