"Bradley D. LaRonde" <brad@xxxxxxxxxxx> writes: >> An object should never use stubs if takes the address of the function. >> It should only use a stub for some symbol foo if every use of foo is >> for a direct call. > > OK. So in a case where an object does take a pointer, does that mean that > ld.so must fix the GOT entry for that symbol before handing control to the > app (i.e. no lazy binding for that symbol)? Right. Such objects won't use a stub, they'll just have a normal reference to an undefined symbol. The dynamic loader must resolve it in the usual way. > I notice that the debian mipsel libpthread.so.0 in > http://ftp.debian.org/pool/main/g/glibc/libc6_2.2.5-11.5_mipsel.deb has > st_value == 0 for every UND FUNC, just like my x86 debian libraries. This > is very different than the uClibc libpthread.so where every UND FUNC has > st_value != 0. Interestingly if I link glibc's libpthread with uClibc's > libc.so I see that most UND FUNCs then have st_value != 0. You said in your original message that you'd recently upgraded to binutils 2.15-based tools. Was your libpthread.so built with them? If so, that would explain it. I think earlier versions of ld were overly pessimistic about when stubs could be used. FWIW, I have a glibc-based sysroot built with gcc 3.4 and binutils 2.15. Its libpthread uses plenty of stubs. Richard
