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

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

On 9 May 2013 18:11, Philippe Waroquiers <phi...@sk...>wrote:

> On Thu, 2013-05-09 at 17:42 -0400, Siddharth Nilakantan wrote:
>
> >
> >         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 your program is statically linked, then the LD_PRELOAD will have
> no effect, which matches the behaviour you see:
>
> > 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
>
> > 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 ?
> The WRAP macros are creating specific function names recognised by
> the debug info loader. I suggest you use nm on your static executable
> to look at these WRAP generated function names and see that they
> look like what you expect (e.g. similar to the wrap1 example).
>
> I ran an nm on the static executable and I didn't see any symbols. Upon
further investigation, both steps involved compilation mistakes.
In one of the steps, I had created a static library of my wrapper code and
tried to link that in, and I believe the linker just didn't include it as
it didn't help
resolve any undefined symbols. Whereas linking the .o produced the symbols
in my static executable and the intercepts work just fine. I feel silly now.
Thanks for your times!

>
> >
> > $ 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.
> If the redir/wraps are not visible in the TOPSPEC trace, then
> they will not be able to match.
>
> Philippe
>
>
>
>