This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [Fwd: Overriding glibc functions]
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Jeremy Fitzhardinge <jeremy at goop 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: Fri, 18 Oct 2002 23:01:57 -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> <1034992203.17417.66.camel@ezr>
On Fri, Oct 18, 2002 at 06:50:02PM -0700, Jeremy Fitzhardinge wrote:
> 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 think A will always use the original foo. BTW, if libB.so is
dlopened, it becomes very tricky. See
http://sources.redhat.com/ml/libc-alpha/2002-05/msg00214.html
H.J.