|
From: Jeremy F. <je...@go...> - 2002-10-20 18:35:52
|
On Sun, 2002-10-20 at 04:00, Julian Seward wrote:
Jeremy
Not entirely sure what the outcome of this is -- can you summarise? I get
the impression that it _should_ be OK -- libpthread.so should override libc
-- but perhaps I'm wrong?
Yes, but... The case where a program binds to some symbols, then
(implicitly) loads libpthread and becomes multithreaded is difficult,
because any previously bound references will remain bound. glibc w/
pthreads has this problem as well (libpthread wants to intercept fork(),
but may not get to it in time).
I think the safe and sure way of making this always work is to make
valgrind.so define all the symbols we want to intercept, and then have
it dispatch them out to our libpthread or into the real libc, depending
on whether a second thread has been created. I think this is certain to
catch all the references we want to catch under all circumstances.
A couple of other points.
1. Your __select and __poll renamings suffer from the same problem.
As do all the libc intercepts in libpthread.so (select and __select are
strong aliases and are therefore indistinguishable
2. I didn't mention this before, but ... you might want to play with the
coregrind/dosyms script. This compares the exported symbols from
V's libpthread.so vs those from the standard one; and it is how I
navigate this swamp -- to a first approximation I try and make
V's libpthread.so export the same syms as the standard one.
OK. It looks to me like the version script mechanism can also be used
to make sure there's no symbol namespace leakage (ie, it can enforce the
rule that only vgPlain_* symbols are visible outside the .so).
J
|