On Thu, Nov 19, 2009 at 00:34, Mike Frysinger wrote: > 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.
although this would cause a TEXTREL which is probably even worse as it negates the entire point of us implementing FDPIC in the first place. screw it. -mike _______________________________________________ Toolchain-devel mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/toolchain-devel
