This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Emacs Development <Emacs-devel at gnu dot org>
- Date: Mon, 18 Jan 2016 23:44:54 +0100
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com> <569D4207 dot 4060209 at cs dot ucla dot edu>
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