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: DJ Delorie <dj at redhat dot com>
- To: fweimer at redhat dot com (Florian Weimer)
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 19 Apr 2017 15:30:51 -0400
- Subject: Re: [PATCH] manual: Document replacing malloc [BZ #20424]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dj at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2A0E531F411
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2A0E531F411
fweimer@redhat.com (Florian Weimer) writes:
> +linked programs, this happens through ELF symbol interposition. For
> +static linking, the @code{malloc} replacement library must be linked in
> +before linking against @code{libc.a} (explicitly or implicitly).
Note that in statically linked cases, it's important to make sure that
ALL your API functions are linked in. If your allocator is a library,
with one function per object, you might get only some of your functions
- and then try to get the rest from glibc, which will of course fail.
> +The @code{malloc} implementation in @theglibc{} provides additional
> +functionality, which is often used by other system libraries and
> +applications. Failure to provide these functions can lead to linking
> +failures and crashes at run time. These additional functions are listed
> +in the following table.
Might be useful to clarify that the first list is what glibc itself
needs, and the second is functions not used by glibc but (as noted)
possibly used by your application.
I.e. /functionality/functionality which is not used within glibc itself/
> +Further @code{malloc}-related functions such as @code{mallopt} or
> +@code{mallinfo} will not have any effect or return incorrect statistics
> +when a replacement @code{malloc} is in use. However, failure to replace
> +these functions typically does not result in crashes or other incorrect
> +application behavior.
mallopt() is in our malloc.c so that would cause a link failure when
static linking, though.