|
From: Julian S. <js...@ac...> - 2002-10-20 20:27:26
|
> 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. How about just link in our libpthread.so under all circumstances? Surely the magic hacks it does for some functions (select, poll, etc) are harmless for single-threaded programs, just a little inefficient? Is there any advantage to the added complication of switching behaviours depending on whether or not a second thread has been created? All else being equal I prefer to avoid complexity like that. > 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 Blargh. J |