|
From: Jeremy F. <je...@go...> - 2004-02-18 17:44:59
|
On Wed, 2004-02-18 at 03:37, Doug Rabson wrote: > On Wed, 2004-02-18 at 11:07, Nicholas Nethercote wrote: > > > ------------- > > > "Pthreads support is improving, but there are still significant > > > limitations in that department. See the section above on Pthreads. Note > > > that your program must be dynamically linked against libpthread.so, so > > > that Valgrind can substitute its own implementation at program startup > > > time. If you're statically linked against it, things will fail badly." > > > ------------- > > > > Interesting question for FV: if a program is statically linked, and it > > uses pthreads, can Valgrind handle it? V's libpthread.so won't replace > > libc's, will it? > > None of valgrind's overrides (malloc, free etc.) will work for static > programs. That's true, but it would be easy to fix. For the most part, V doesn't rely on ld.so for intercepting symbols anymore, it uses code redirection. At the moment it specifically looks for malloc/free/etc in libc.so, but it would be easy to make it look them in the main executable (assuming that functions which happen to be named malloc/free/etc are actually functionally equivalent to the libc versions). libpthread is different, since we do actually need to replace it outright. Once we start doing a proper clone() emulation, this won't be an issue. J |