This is the mail archive of the
mailing list for the glibc project.
Re: The direction of malloc?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at suse dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Tue, 10 Dec 2013 18:42:10 +0100
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <CANu=Dmi32gwk-hQ3dDbj0d4_gs3FWqt02+NmveXH1p03Vm+Mfg at mail dot gmail dot com> <20131210111031 dot GH5048 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1312101654500 dot 15324 at digraph dot polyomino dot org dot uk>
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
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.