"Bradley D. LaRonde" <brad@xxxxxxxxxxx> writes: > I guess that the point of these procedure stubs is to keep > pointer-to-function values consistent between executables and share > libraries. Is that what binutils is trying to accomplish here? No, it's to enable lazy binding. The idea is that when the dynamic loader loads libpthread.so, it doesn't need to resolve malloc() immediately, it can just leave the GOT entry pointing to the stub. Then, when the stub is called, it will ask the dynamic linker to find the true address of malloc() and update the GOT accordingly. This is supposed to reduce start-up time. 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. If the dynamic loader is choosing libpthread's stub over the real definition in libc.so, that sounds on the face of it like a dynamic loader bug. > But should stubs really be getting involved here? As Thiemo Seufer pointed > out to me, readelf shows me that every undefined symbol in every shared > library in /lib on my x86 debian box has the st_value member for the symbol > table entry set to zero. The x86 and MIPS ABIs are very different though. Richard
