Re: [Valgrind-developers] malloc (a new lib) not in uclibc, and we could not use valgrind, could you give me some advice ?

[Andrew C. M. <and...@gm...>]

On Mon, Feb 20, 2012 at 3:25 PM, Philippe Waroquiers
<phi...@sk...> wrote:
>
>
> For this, you must modify the file
> coregrind/m_replacemalloc/vg_replace_malloc.c
>
> For example, for malloc, you currently have:
>  ALLOC_or_NULL(VG_Z_LIBSTDCXX_SONAME, malloc,      malloc);
>  ALLOC_or_NULL(VG_Z_LIBC_SONAME,      malloc,      malloc);
>
> I believe if you add a line
>  ALLOC_or_NULL(VG_Z_YOURLIB_SONAME,      malloc,      malloc);
> where VG_Z_YOURLIB_SONAME is to be defined similarly to others
> in include/pub_tool_redir.h, then this should work.
>

I have done this a few times, most often to add support for Google's
tcmalloc library to valgrind. The current structure of
vg_replace_malloc.c means you must either make many small and widely
separated edits to different areas of the file, one for each new
interception, or not honor the organization of the file. If you do
follow the current organization, then each edit site is complex,
having nested #ifdefs, commented out regions, varying mangled names,
etc. This makes maintaining a patch to support an alternative
allocator harder, since there are often multiple non-trivial conflicts
when upstream vg_replace_malloc.c changes.

I've attached a sketch for a patch that moves all of the interception
applications to a common area at the end of vg_replace_malloc.c, right
before 'init'. In addition, the patch merges the relevant VGO_linux
and VGO_darwin conditional compilation sections, macro-izes the
mangled new/delete signatures to abstract away VG_WORDSIZE variation,
and groups the interceptions for each platform by library. The file
seems much simpler this way, and it could be simplified further if it
is determined that the many currently commented out Darwin
interceptions can be removed. I left the Darwin conditional
compilation things alone because I was unsure about the intended
semantics.

Arranged this way, I think it is much easier to see the overall
structure of the interceptions for each platform and library. This
should make it easier to see how and where to add support for other
allocators and to maintain the resulting patch as vg_replace_malloc.c
evolves. Thoughts?

Thanks,
Andrew