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: Stefan Monnier <monnier at iro dot umontreal dot ca>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: emacs-devel at gnu dot org, libc-alpha at sourceware dot org
- Date: Sat, 23 Jan 2016 17:19:44 -0500
- 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> <jwvr3h8uxlc dot fsf-monnier+emacs at gnu dot org> <83wpr047nd dot fsf at gnu dot org>
> I don't understand the last part of this at all.
> AFAIU, the problem is not with Lisp data, the problem is with memory
> allocations on the C level that are not on behalf of Lisp data. We
> need to find a way of doing that without relying on that data be
> fee'able after dumping.
The part you didn't understand was specifically referring to the fact
that preloaded Lisp data can also be freed (by the GC) and that in turn
can also lead to calls to `free'.
Stefan