This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The direction of malloc?

On 10 December 2013 17:00, 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).

Is that actually possible? I thought malloc_get_state just returned an
opaque pointer so I wasn't aware it could be written out to any kind
of storage or last longer than the lifetime of a process.

Will Newton
Toolchain Working Group, Linaro

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]