Re: [Valgrind-developers] valgrind/coregrind

[Nicholas N. <nj...@ca...>]

On Thu, 3 Jun 2004, Tom Hughes wrote:

> > > Changed cancellation wrappers to use dlsym(RTLD_NEXT) to look up the
> > > libc version of the wrapped function when forwarding the call rather
> > > than trying to call the internal __libc_xxx version of the routine
> > > as many of those are marked as GLIBC_PRIVATE in recent releases.
> >
> > Will this work if libc is stripped?
>
> You can't strip the dynamic symbol table from a shared library if
> you want it to actually work... Note that it isn't the __libc_xxx
> functions I'm forwarding to, it's the original names that are being
> overridden by the pthread library.
>
> The only thing I'm not sure about is statically linked programs
> but I'm not sure you can statically link a multithreaded program.

You can -- I just tried it.  But Memcheck didn't like it, gave lots of
uninitialised warnings and then bombed out with:

  ==29475== Valgrind detected that your program requires
  ==29475== the following unimplemented functionality:
  ==29475==    clone(): not supported by Valgrind.
     We do now support programs linked against
     libpthread.so, though.  Re-run with -v and ensure that
     you are picking up Valgrind's implementation of libpthread.so.

I guess V's libpthread.so isn't overriding the statically linked system
one.

N