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

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 20 Dec 2015 14:33:22 -0800
> Cc: Rich Felker <dalias@aerifal.cx>, 22086@debbugs.gnu.org
> 
> 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.

Wouldn't memory allocated with emallooc conflict with uses of malloc
in the startup code?

Other than that, I'm okay with leaving gmalloc.c's allocator under a
different name.  Removing it is something we should consider
separately.

> 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.

Why is it obsolete?