This is the mail archive of the
libc-alpha@sourceware.org
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: Will Newton <will dot newton at linaro dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, 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 23:17:46 +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> <CANu=Dmi5mr9z4P99LDB+8q6_1XcNraeofyScgFdwqOhZMBTTGQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1312101801170 dot 15324 at digraph dot polyomino dot org dot uk>
On Tue, Dec 10, 2013 at 06:04:04PM +0000, Joseph S. Myers wrote:
> On Tue, 10 Dec 2013, Will Newton wrote:
>
> > > 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.
>
> The main purpose of malloc_get_state / malloc_set_state is for use by
> emacs. If emacs adopted a better approach I'd happily deprecate them -
> turn them into compat symbols - but you still need to support them
> indefinitely with existing emacs binaries, as a matter of binary
> compatibility. (Support could mean such binaries - binaries using the
> malloc_set_state compat symbol - use a different copy of malloc in libc
> from what all other binaries use, if necessary.)
>
For these we could detect that old allocator with nearly zero overhead
by loading alternate implementation lazily if malloc_set_state is used.
These could be detected in runtime linker as below. Must we support calls
from dlopened libraries (as there are only 10000 google hits of
malloc_get_state I doubt that anybody tried that.)
index f869dcf..10d277d 100644
--- a/elf/dl-lookup.c
+++ b/elf/dl-lookup.c
@@ -765,10 +765,18 @@ _dl_lookup_symbol_x (const char *undef_name, struct link_map *undef_map,
if (__builtin_expect (current_value.s == NULL, 0))
{
+ if (!strcmp (undef_name, "malloc_get_state")
+ || !strcmp (undef_name, "malloc_set_state"))
+ {
+ install_old_allocator ();
+ return 0;
+ }
+
if ((*ref == NULL || ELFW(ST_BIND) ((*ref)->st_info) != STB_WEAK)
&& skip_map == NULL
&& !(GLRO(dl_debug_mask) & DL_DEBUG_UNUSED))