Re: [Valgrind-developers] intercepting statically linked pthread binaries

[Philippe W. <phi...@sk...>]

On Wed, 2013-05-08 at 16:50 -0400, Siddharth Nilakantan wrote:
> Hi All,
> 
> 
> 
> Is it possible to intercept pthread API calls when the libraries are
> linked statically? I successfully did intercepts on dynamically linked
> pthread libraries, but the requirements of my project need me to use
> statically linked -lpthread. I tried using a soname of NONE, so my
> interceptor looked like
> 
> 
> int
> I_WRAP_SONAME_FNNAME_ZZ(NONE,pthreadZumutexZulockZa)(pthread_mutex_t
> *mutex){
> 
>   int ret;
>   OrigFn fn;
>   VALGRIND_GET_ORIG_FN(fn);
>   printf("Entered pthread_mutex_lock %lu!\n",mutex);
> 
>   CALL_FN_W_W(ret, fn, mutex);
>   printf("Leaving pthread_mutex_lock %lu!\n",mutex);
>   return ret;
> 
> }
> 
> 
> but that didn't work.

Is the 'I_WRAP_...' code itself statically linked ? Or is it in an .so ?

If you add -v -v -v -d -d -d --trace-redir=yes, is there some
indications of what is going wrong ?
For example, when the debug info of the executable (or .so)
in which you have the I_WRAP_... is loaded, it should indicate
that it is finding some 'TOPSPECS'.

You can compare your behaviour with the behaviour of the regression
tests testing the I_WRAP_... functionality.
For example, the test memcheck/test/wrap1 wraps
a function called "actual", trace gives:
==2457== Adding active redirection:
--2457--     new: 0x08048464 (actual              ) W-> (0000.0) 0x08048478 actual
--2457-- <<
--2457--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--2457--    TOPSPECS of soname NONE filename /home/philippe/valgrind/trunk_untouched/memcheck/tests/wrap1
--2457--      NONE                      actual                         W-> (0000.0) 0x08048478

> 
> 
> I also tried "--soname-synonyms=somalloc=NONE" just to get it to try
> replacement in static binaries, but I dont' think that is the right
> usage nor was it built for that purpose. 
The --soname-synonyms= command line argument has been done so as
to allow synonyms to be specified for other libs than the malloc
lib, but such synonym flexibility implies some work for each
"flexible" library replacement. See
coregrind/coregrind/m_replacemalloc/vg_replace_malloc.c
and search for SO_SYN_MALLOC