Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> Cc: Eli Zaretskii <address@hidden>, address@hidden,
>         address@hidden, address@hidden
> From: Florian Weimer <address@hidden>
> Date: Tue, 26 Jan 2016 23:17:35 +0100
> 
> On 01/23/2016 11:52 PM, Richard Stallman wrote:
> 
> [realloc/free of a dumped heap object]
> 
> > It may be a pain to fix them if they happen inside libraries.
> 
> I think the dump-and-reload cycle resets global variables defined in
> libraries as long as they are not referenced by the main program.  This
> means libraries have difficulties to retain references to objects
> allocated before the dump.
> 
> If Emacs retains such references and passes them to a library, such
> boundary-crossing heap operations could still happen.  But some
> libraries will get very confused if they are handed an object while
> their internal state says they have not created any objects yet.  (Which
> is how we got __malloc_get_state and __malloc_set_state, I assume.)
> 
> Has it already happened that an innocent-looking library change causes
> existing Emacs binaries to break?  Apart from when glibc tried to fix
> the incorrect object alignment on 32-bit PowerPC?

AFAIK, Emacs has no reason to call any libraries in temacs except libc
(and its logical extensions, like libm).