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

[Siddharth N. <sn...@dr...>]

Philippe, thanks for the response. My comments are below.

Sid

On 9 May 2013 02:14, Philippe Waroquiers <phi...@sk...>wrote:

> 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 ?
>
> It was not statically linked. The I_WRAP function is in a separate source
file that I compiled and LD_PRELOADed (libwrapper.so)
and the instrumented program has the functions I am looking to wrap
(Pthread API calls)


> 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'.
>
> It seems like the debuginfo for the libwrapper.so is never loaded at all.
I don't see any TOPSPECS for it. I do see TOPSPECS for the instrumented
program

--2346--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--2346--    TOPSPECS of soname NONE filename
/home/DREXEL/sn446/experiments/sigilprof_threads_memtrace/custom/toy_memtrace/v6/changed_source/toy_memtrace
--2346--    ------ ACTIVE ------
--2346--     0xffffffffff600000 (???                 ) R-> (0000.0)
0x3803bae3 ???
--2346--     0xffffffffff600400 (???                 ) R-> (0000.0)
0x3803baed ???
--2346--     0xffffffffff600800 (???                 ) R-> (0000.0)
0x3803baf7 ???

I see these in wrap1 and even when I remove wrapping altogether. I believe
they correspond to some default stuff: vgettimeofday,vtime,vgetcpu

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
>
> When I compile memcheck/test/wrap1 statically, I see the same thing as
your example (as in the wrapping occurs successfully).

So in the next step, I statically linked my wrapper object file with my
instrumented program. I still did not see any TOPSPECS
for the wrapped function. Finally, I moved the wrapper code to the
instrumented program, I still did not see any change. Maybe
the wrapper itself is written incorrectly and not matching with the
correspdonding pthread function in libpthread.a ?

$ nm /usr/lib/libpthread.a --demangle | grep mutex gives

         U pthread_mutex_lock
pthread_mutex_lock.o:
0000000000000420 T __pthread_mutex_lock
0000000000000000 t __pthread_mutex_lock_full
0000000000000420 T __pthread_mutex_lock_internal
0000000000000420 T pthread_mutex_lock

and I use "pthreadZumutexZulockZa" for FNPATT so I'm not sure why it
doesn't match.

>
> >
> > 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
>

Thanks, if my wrappers are not too many, I can just  write a wrapper for
each synonym, so I'll do that for now, when I am able to intercept pthread
calls.

>
>