On Mon, 21 Feb 2011, Mike Frysinger wrote:
> The fdpic code requires two 32bit values to be read/written atomically
> (one pointer for the GOT and one for the PLT). FRV has an insn to do
> this sort of thing, but Blackfin does not. So in order to use FDPIC on
> a threaded system, we need to disable lazy relocation.
This is what the SH FDPIC ABI has to say on this subject. I'm not sure
what was needed in the resolver to implement it (though when I wrote the
ABI we convinced ourselves it was implementable).
1) Fill in the function descriptor in the caller's GOT so that the
entry point and GOT address are correct for the next call of
the resolved function. As in the Blackfin FDPIC ABI, there is
a race condition between both words getting written and some
other thread attempting to read them, and no atomic 64 bit
load/store instruction that could be used to prevent it. To
avoid problems arising from this race, when function
descriptors are read the entry point must be read before the
FDPIC pointer, and when the resolver writes them it must write
the new FDPIC pointer before writing the new entry point. This
leaves the possibility of a lazy PLT entry (and so the
resolver) being called with the FDPIC register pointing to the
GOT for the load module containing the called function instead
of the load module containing the call and GOT and PLT entries,
if the call is made after the resolver was interrupted between
updating the two words of the function descriptor; the resolver
must allow for this possibility. In addition, the resolver may
need to use locking to ensure that two different threads are
not updating a function descriptor at the same time to point to
functions in two different load modules.
--
Joseph S. Myers
jos...@codesourcery.com
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
