This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [Fwd: Overriding glibc functions]
- From: Jeremy Fitzhardinge <jeremy at goop dot org>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: Valgrind Developers <valgrind-developers at lists dot sourceforge dot net>,Robert Walsh <rjwalsh at durables dot org>,Nicholas Nethercote <njn25 at cam dot ac dot uk>,Julian Seward <jseward at acm dot org>,GNU C Library <libc-alpha at sources dot redhat dot com>
- Date: 18 Oct 2002 18:50:02 -0700
- Subject: Re: [Fwd: Overriding glibc functions]
- References: <1034983974.17684.31.camel@ezr><20021018165810.A13953@lucon.org> <1034987181.17416.46.camel@ezr> <20021018175230.A14734@lucon.org>
On Fri, 2002-10-18 at 17:52, H. J. Lu wrote:
> > OK, but valgrind.so is already being linked with "-z initfirst"; what
> > happens if there are two .so files with initfirst? (It does seem to
> > work).
>
> Which ever comes first wins
So if the order of events is:
1. run executable A, with LD_PRELOAD=valgrind.so (which has initfirst
set)
2. A uses function foo() which is defined in libc.so
3. A doesn't use libpthread, but after a while it dlopens libB.so, which
does
4. libB.so pulls in Valgrind's libpthread.so.
5. Valgrind's libpthread.so wants to override foo(), now that this has
become a multithreaded program. If A uses foo() again, which definition
will it get? libc's original one (which it was using before), or the
new definition in libpthread.so?
I wonder if the solution is to always pull in Valgrind's libpthread.so,
but only make it do special stuff once there's more than one thread...
Thanks,
J