bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc patch for elf systems

[Rich Felker]

On Sun, Dec 20, 2015 at 02:33:22PM -0800, Paul Eggert wrote:
> While thinking over this patch I'd like to propose what should be a
> simpler approach. This new proposal is more radical, and so should
> not be applied to the emacs-25 branch, but it should make the port
> to musl etc. automatic.
> 
> The simpler approach is to remove gmalloc.c, and to use the system
> memory allocator, i.e., to behave as if SYSTEM_MALLOC is defined on
> all platforms.
> 
> We can still support hybrid malloc for Cygwin, if SYSTEM_MALLOC
> wouldn't work on Cygwin for some reason; and we can support the
> similar hybrid on Darwin, if it's still needed. But in neither
> approach should we override the system malloc; any Emacs-specific
> allocation function we define should be called (say) emalloc instead
> of malloc, so that it does not conflict with the system malloc. That
> way, we don't have to worry about name-space collisions, either at
> compile-time or at link-time.
> 
> If I'm wrong about gmalloc.c and it is still needed on some
> platforms for some reason, we can continue to use it, but it should
> define emalloc etc., and not attempt to override the C standard
> library.
> 
> Long ago as I recall, we really needed to override the C standard
> library on some platforms, due to the funny way in which undumped
> storage was made read-only. That need is obsolete, though, which
> should let us simplify things now.

I don't object to this change if you can reliably ensure that nothing
in the pre-dump emacs will call malloc. When I looked, though, this
seemed to be very difficult; I had been looking (albeit casually) for
a clean solution to this problem for nearly a decade before hybrid
malloc showed up. Unless there's a quick solution I think switching to
hybrid malloc would be a first good step, but I like eliminating
gmalloc.c better.

Rich