On Tuesday, February 22, 2011 12:40:08 Andrew Stubbs wrote: > On 22/02/11 17:06, Joseph S. Myers wrote: > > 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). > > Right, the resolver makes sure that it does not make any assumptions > about the FDPIC value passed in. > > It compares the value given with the load-map, and if it falls outside > the address range for the proper module, it walks the module list, and > finds the correct one.
hmm, interesting approach. i'd def like to take a look at this. > The patches were never posted to uClibc because the GCC patches were not > accepted. At the time, there were also problems with upstream uClibc not > building for MMU-less targets. i dont think gcc superh support in mainline is a hard requirement to merge the FDPIC bits. especially since some of it sounds like it's arch independent. > I can provide the work-in-progress patches for reference, if you wish, > or you could look at the sources for Sourcery G++ Lite for SH uClinux > here: http://www.codesourcery.com/sgpp/lite/superh is it in a git tree somewhere ? how about creating a superh-fdpic branch in the uclibc.org git tree and pushing that out ? i dont think we use branches enough :) -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
