|
From: Jeremy F. <je...@go...> - 2002-10-18 23:12:58
|
On Fri, 2002-10-18 at 13:53, Julian Seward wrote: > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgsnd > 000e76c8 T msgsnd > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgrcv > 000e771c T msgrcv > > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgsnd > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgrcv > > IOW, msgsnd/msgrcv are exported as strong text symbols from libc, and not > at all from libpthread. Your patch adds them to valgrind's libpthread.so. > So any threaded program running on V will have two definitions of > them to choose from, and it is unclear which it will get. If the libc > version was defined as a weak symbol, then V's implementation would > definitely overrride it (and many libc things are indeed exported weakly) > but that is not the case. > > Does that make sense? Is there some other behaviour of the dynamic > linker which might save the day and avoid this issue? I don't know much > about ld.so; perhaps you understand more about all this? Hm, no, but I know who does. Hey, HJ: We have the problem that Valgrind's implementation of libpthread.so needs to intercept various libc functions (in this instance msgsnd/msgrcv) so it can make sure they only block the thread rather than the whole process (since Valgrind completely re-implements the thread library without using kernel threads). The question is which definition will be picked up when glibc's function definition is not a weak reference? How can we make sure that our libpthread version is preferred over the glibc version? One thing occurs to me: the main Valgrind shared object, valgrind.so, is always LD_PRELOADED, and is linked with -Wl,-z -Wl,initfirst. I wonder if the solution is to put the intercept stub functions in valgrind.so, and have them call either glibc or libpthread, depending on the context. Thanks, J |