|
From: H. J. L. <hj...@lu...> - 2002-10-18 23:58:17
|
On Fri, Oct 18, 2002 at 04:32:53PM -0700, Jeremy Fitzhardinge wrote: > Hi HJ, > > Oops. I guess lucon.com is dead to you. Let's see if this works. Is lucon.com available? I may switch to that. In the meantime, please email me at hj...@lu... :-). Jeremy, drop me a line if you want to make autofs 4.0. Content-Description: Forwarded message - Overriding glibc functions > Subject: Overriding glibc functions > From: Jeremy Fitzhardinge <je...@go...> > To: hj...@lu... > X-Mailer: Ximian Evolution 1.0.8 > Date: 18 Oct 2002 16:12:56 -0700 > > 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. > There are 2 things you should know: 1. There are supposed to be no differences between weak and strong symbols in DSOs. I submitted a patch to glibc: http://sources.redhat.com/ml/libc-alpha/2001-09/msg00109.html 2. Glibc will make sure libpthread.so will override libc.so, weak or strong. Please file a bug if it doesn't do so. But please make sure your libpthread has: # readelf -d /lib/libpthread.so.0 ... 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST ... by passing "-z nodelete -z initfirst" to ld. H.J. |