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: Eli Zaretskii <eliz at gnu dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: rms at gnu dot org, libc-alpha at sourceware dot org, monnier at iro dot umontreal dot ca, emacs-devel at gnu dot org
- Date: Wed, 27 Jan 2016 05:38:05 +0200
- 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> <569D6AE6 dot 1060008 at redhat dot com> <83bn8icjqu dot fsf at gnu dot org> <jwv60yk7snj dot fsf-monnier+gmane dot emacs dot devel at gnu dot org> <83r3h86aqf dot fsf at gnu dot org> <E1aN72k-00024K-Ep at fencepost dot gnu dot org> <56A7F07F dot 9000109 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Cc: Eli Zaretskii <eliz@gnu.org>, libc-alpha@sourceware.org,
> monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Florian Weimer <fweimer@redhat.com>
> 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).