Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/18/2016 08:50 PM, Paul Eggert wrote:

> Emacs's internal state includes the heap controlled by malloc, as Emacs
> calls malloc before unexec, and the restarted executable also invokes
> malloc. Hence Emacs unexec must take care that the restarted
> executable's malloc doesn't get confused by the ELF munging that unexec
> does when writing out Emacs's internal state. It does this in part by
> calling malloc_get_state just before unexec, and having the restarted
> executable call malloc_set_state during startup (even before 'main' is
> called). This is done via __malloc_initialize_hook, and I expect this is
> the sort of thing that Florian is talking about when he says the glibc
> API is changing.

The main problem is that the heap is laid out in a particular way.  If
we change the heap layout in a glibc update (which we want to do on
powerpc for conformance reasons, for example), then old Emacs binaries
will not start anymore.  We can work around that with compatibility
symbols, but when we fix that, I want to decouple Emacs binaries from
these glibc implementation details, to avoid a repeat of the entire
exercise.

This is less of a problem if Emacs never frees a pointer after dump that
it has allocated before dump.  But I think this can happen (otherwise,
all this would be quite easy to address).

Florian