On Mon, 28 Sep 2026, mironu wrote: > I wanted to fix an RTEMS issue related to thread-local storage on > the MIPS R3900. The R3900 does not support the rdhwr instruction used by > the MIPS backend to access the thread pointer, so RTEMS currently has to > emulate it in its exception handler.
The use of an exception to emulate the missing instruction was the whole point of the design for the Linux TLS ABI, keeping it consistent across ISA implementations. At MTI we considered alternatives such as a syscall or even putting a GPR aside, but concluded the use of RDHWR would be the best compromise, guaranteeing fast emulation, since the RI exception is uncommon and the handler could be optimised for the RDHWR ..., $29 case, and once the CP0.UserLocal has been implemented, which at the time of the design wasn't, and believe me that the hw guys were quite opposed to it, it would be exactly as fast as using a GPR while not sacrificing one and not requiring pre-TLS object code to be rebuilt. > The proposed RTEMS solution is to use a software thread-pointer access > mechanism, similar to the existing ARM -mtp=soft support. This requires > the MIPS GCC backend to provide a corresponding -mtp=soft option that > generates a call to an RTEMS-provided __mips_read_tp helper. > More details here: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5753 Since RTEMS is not Linux, you're of course free to do whatever you like with your target, since you're not bound by the Linux psABI, however I do not like the option of allowing an ABI drift for other targets, so could you please make the GCC option available for RTEMS only? You may want to set it on by default too if you prefer. I wonder if you need to claim a dedicated ELFOSABI_* setting for your ABI variant too. Maciej
