The direction of malloc?

[Ondřej Bílka]

On Tue, Dec 10, 2013 at 05:00:10PM +0000, Joseph S. Myers wrote:
> On Tue, 10 Dec 2013, Siddhesh Poyarekar wrote:
> 
> > A really cool feature would be to have the ability to plug in malloc
> > implementations at least at build time in the beginning and then later
> > at runtime using tunables.  It should be doable by implementing a
> > layer that passes calls on to the selected implementation.  This would
> > have to be implemented using relocation (IFUNC?) since otherwise we're
> > introducing an additional cost.
> 
> Applications can always provide their own malloc, as can an LD_PRELOAD 
> library; calls from libc to malloc functions should already go through the 
> PLT so as to get any replacement malloc.
> 
> One significant difficulty with building a replacement into glibc is 
> supporting malloc_set_state calls with data saved with a previous glibc 
> version - the problem that has so far prevented us from correcting malloc 
> alignment for powerpc32 without breaking emacs (bug 6527 - as noted in 
> that bug, it should be fixed for 32-bit x86 as well to support ISO C 
> extensions such as _Decimal128 properly, if a way to fix it is found).
> 
As malloc_set_state is used pretty much only by emacs it should be
application responsibility (googling . We could provide a fixed layout allocator library 
say malloc_fixstate.so and requiring applications using setstate linking
this one.

Then we drop a malloc_set_state from libc.so to inform about
unavailability by link failure.

Then distributions need to add dependency that upgrading glibc must
upgrade emacs which is doable.