On Wed, Nov 18, 2009 at 06:43, Bernd Schmidt wrote: > Mike Frysinger wrote: >> we've been over the race conditions in threaded FDPIC code many times. >> we've proposed random invasive changes in the past (largely based on >> forcing immediate symbol binding when detecting a threaded >> environment), but now that we have the fixed code region that provides >> atomic functions for userspace, why dont we implement 64bit >> load/stores there ? since the only thing that needs to know about >> updating the FDPIC entries in the GOT is uClibc's ldso, this should be >> pretty straight forward i think ... > > We've been over this. The problem is that we'd need to call the atomic > load everytime we want to call a function, which would be prohibitively > expensive.
blah, that's obvious. i was forgetting half the equation. i guess it isnt possible to stash the resolver's GOT in a dedicated symbol via crti.o and have the resolver stub load that directly. the relocation would be processed by the ldso before any lazy relocations got a chance to load. if the resolver first updated the GOT in the function descriptor followed by the function address, then there wouldnt be any race issues as the resolver stub would simply ignore the GOT given to it. once the function address in the function descriptor is pointing to the right place, the right GOT will have been stored. -mike _______________________________________________ Toolchain-devel mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/toolchain-devel
