Gedare chatted me and said he didn't see the code in the linked assembly for rdhwr. It wasn't obvious and I should have added a bit of commentary.
Look for CPULOCAL. The comments in the CVS log are what tie it to rdhwr and TLS. There may be an outer wrapper for this. I don't know. On 4/28/2014 1:47 PM, Joel Sherrill wrote: > Hi > > This is going to be interesting. MIPS TLS is broken because > we don't have a trap handler for this. From GCC: > > ;; Thread-Local Storage > > ;; The TLS base pointer is accessed via "rdhwr $3, $29". No current > ;; MIPS architecture defines this register, and no current > ;; implementation provides it; instead, any OS which supports TLS is > ;; expected to trap and emulate this instruction. rdhwr is part of the > ;; MIPS 32r2 specification, but we use it on any architecture because > ;; we expect it to be emulated. Use .set to force the assembler to > ;; accept it. > ;; > ;; We do not use a constraint to force the destination to be $3 > ;; because $3 can appear explicitly as a function return value. > ;; If we leave the use of $3 implicit in the constraints until > ;; reload, we may end up making a $3 return value live across > ;; the instruction, leading to a spill failure when reloading it. > > This code from NetBSD appears to be the core part of the > handler. > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/locore_mips3.S?only_with_tag=MAIN > > If someone can adapt this, then the MIPS will have working > TLS. > > Thanks. > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
