[PATCH] Allow to use different prefixes for jemalloc-specific functions and libc functions

[Mike Hommey]

On Thu, Mar 01, 2012 at 05:49:33PM -0800, Jason Evans wrote:
> On Mar 1, 2012, at 6:44 AM, Mike Hommey wrote:
> > On Wed, Feb 29, 2012 at 04:15:37PM -0800, Jason Evans wrote:
> >> On Feb 23, 2012, at 3:23 AM, Mike Hommey wrote:
> >>> From: Mike Hommey <mh at glandium.org>
> >>> 
> >>> In some cases, it can be interesting to use different prefixes for
> >>> the "standard" libc malloc functions and for jemalloc specific
> >>> functions. One such case is to use the "__wrap_" prefix on libc
> >>> malloc functions (for use with ld's --wrap option) and no prefix or
> >>> "je_" for jemalloc functions.
> >>> 
> >>> In such cases, it can also me interesting not to exclude memalign
> >>> and valloc, so this change also adds an option not to omit them when
> >>> the prefix is set.
> >> 
> >> Do you have a practical use case that makes this a compelling feature?
> >> I'm reluctant to hard-code the set of JEMALLOC_LIBC() functions to
> >> make distinct from JEMALLOC_P() functions, because it may vary by
> >> operating system.
> > 
> > The exact one that is in the patch message: on android, we use ld's
> > --wrap option to wrap the "standard" libc functions. It is cumbersome
> > to have to use --wrap for jemalloc-specific functions as well.
> > Arguably, we could probably use symbol aliases when linking the library
> > containing jemalloc.
> 
> I went a slightly different direction with this and added --with-mangling:
> 
>   http://www.canonware.com/cgi-bin/gitweb.cgi?p=jemalloc.git;a=commitdiff;h=0a5489e37da88a1a50fbf8552e0d3a7f8fd93ffc
> 
> Please let me know if this fails to meet your needs for some reason.

The fact that --with-jemalloc-prefix overrides anything set with
--with-mangling makes it unconvenient for our usecase, where we want to
prefix with je_ except a few functions we want to either not prefix (on
desktop) or wrap (on android). Sure, we can use --with-mangling to set
the je_ prefix, but that won't cover new APIs when they appear.

Cheers,

Mike