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: Emacs Development <Emacs-devel at gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 19 Jan 2016 00:15:01 +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>
On 01/18/2016 08:24 PM, Paul Eggert wrote:
> Can you explain the problem in more detail? What are the symptoms if you
> do the following with the next-generation glibc API?
>
> git clone --branch emacs-25 git://git.savannah.gnu.org/emacs.git
> cd emacs
> ./autogen.sh
> ./configure
> make
This doesn't work with current glibc and the current Emacs configure.ac
file. It doesn't seem possible to get rid of the dlmalloc detection
without editing configure.ac.
> Is there some way that Emacs developers (who are typically not glibc
> experts) can easily test with the next-generation glibc API?
I don't have the new API yet. It will likely consist of the C and POSIX
APIs exclusively (that is, no hooks, no malloc_set_state). The easiest
way is likely to trick configure into believing that it's not on glibc
malloc. If the resulting post-dump binary runs under valgrind or with
another malloc implementation such as jemalloc or tcmalloc preloaded, it
will likely work with future glibc versions.
I did the configure.ac edit, and Emacs chose to use gmalloc.c, and the
resulting binary works, even under valgrind. Looking at its symbols,
it's immune to malloc preloading due to the built-in malloc definition.
This should continue to work, but you now have to maintain your own malloc.
Florian