Re: [PATCH] Allow direct access to dlmalloc

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Yaakov,

On Sep  1 16:41, Yaakov Selkowitz wrote:
> This allows programs to override malloc/free/etc. while still being able
> to access the internally provided implementation.
> 
> * common.din (__libc_calloc): Export.
> (__libc_free): Export.
> (__libc_mallinfo): Export.
> (__libc_malloc): Export.
> (__libc_mallopt): Export.
> (__libc_memalign): Export.
> (__libc_realloc): Export.
> (__libc_valloc): Export.
> * malloc_wrapper.cc (__libc_free, free): Split out builtin dlmalloc
> implementation into separate function.
> (__libc_malloc, malloc): Ditto.
> (__libc_realloc, realloc): Ditto.
> (__libc_calloc, calloc): Ditto.
> (__libc_memalign, posix_memalign, memalign): Ditto.
> (__libc_valloc, valloc): Ditto.
> (__libc_mallopt, mallopt): Ditto.
> (__libc_mallinfo, mallinfo): Ditto.
> ---
> This came to my attention due to:
> 
> https://git.gnome.org/browse/gdk-pixbuf/commit/?id=b07c3bf
> 
> Although this will likely be changed due to it being unable to link
> on anything not using glibc.

Right.  The patch looks ok, but do we really want to go there?  These
__libc_* symbols are very much an internal and (probably?) undocumented
implementation detail of glibc.  The aformentioned case is not even
production code but just a test and even that is eventually going to be
changed for portability reasons as you pointed out.

Unfortunately it seems not possible to make the __libc_* symbols simply
a set of aliases for existing functions.  So, is it really worth the
additional function call per each malloc?  Granted, you'll probably only
notice the slowdown on 32 bit, but still...?

> The one question I have about this patch is that I see in a couple other
> places that malloc-overriding code tries to override the __libc_* variants
> as well on Linux (where they are just weak aliases to the main functions).
> This particular method wouldn't allow that, but I'm not sure if we want or
> need to allow that either.

You'd need another set of malloc/calloc/realloc/free pointers in struct
per_process.  We still have room for 9 pointers in per_process without
having to resize it.  Doable, yes.  Worth it?  I'm not so sure.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpJZTufIRGD2.pgp
Description: PGP signature