This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] manual: Document replacing malloc [BZ #20424]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, DJ Delorie <dj at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>
- Cc: nd at arm dot com, libc-alpha at sourceware dot org
- Date: Wed, 3 May 2017 11:08:58 +0200
- Subject: Re: [PATCH] manual: Document replacing malloc [BZ #20424]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BF1573D942
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BF1573D942
- References: <xn8tmwgkmj.fsf@greed.delorie.com> <c05f8996-6cc6-b9ee-0f94-f78ba0cf3bd8@redhat.com> <58FE3320.2040008@arm.com>
On 04/24/2017 07:17 PM, Szabolcs Nagy wrote:
On 20/04/17 11:53, Florian Weimer wrote:
+@node Replacing malloc
+@subsection Replacing @code{malloc}
+
+@cindex @code{malloc} replacement
+@cindex @code{LD_PRELOAD} and @code{malloc}
+@cindex alternative @code{malloc} implementations
+@cindex customizing @code{malloc}
+@cindex interposing @code{malloc}
+@cindex preempting @code{malloc}
+@cindex replacing @code{malloc}
+@Theglibc{} supports replacing the built-in @code{malloc} implementation
+with a different allocator with the same interface. For dynamically
+linked programs, this happens through ELF symbol interposition, either
+using shared object dependencies or @code{LD_PRELOAD}. For static
+linking, the @code{malloc} replacement library must be linked in before
+linking against @code{libc.a} (explicitly or implicitly).
+
this documentation does not mention known caveats, e.g.
There are many more, like following ABI requirements regarding alignment
and pointer bit patterns.
- when wrapping calloc via dlsym, dlsym may call calloc, the
user has to deal with it,
- similarly any interface that internally may use malloc (in
the future) better not be used in the malloc implementation.
- malloc may be called when locks are held (e.g. some stdio
lock during scanf) so synchronizing with anything that might
also hold the same lock in the malloc implementation may
deadlock (a more interesting example is probably the dl_load_lock
while allocating dynamic tls in some cases so a user provided
malloc should not use dtls)
It should be able to use initial-exec TLS, though.
Is it really worthwhile to go into such details? The malloc/fork
interaction is something mostly dependent on malloc implementation details.
I can add a general warning to the documentation that implementing
malloc is not easy, but I'm not sure how helpful it would be.
The symbol list is mainly there because jemalloc forgot to override
__libc_memalign for older glibcs, and we don't want a repeat of that.
Thanks,
Florian