On Thu, Jun 25, 2020 at 1:34 PM Joel Sherrill <j...@rtems.org> wrote: > > On Thu, Jun 25, 2020 at 2:54 PM Nathan Sidwell <nat...@acm.org> wrote: > > > On 6/25/20 2:34 PM, Joel Sherrill wrote: > > > Hi > > > > > > RTEMS supports over 15 processor architectures and we would like to > > ensure > > > that TLS is supported on all rather than just a handful of popular ones > > > (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document ( > > > https://www.akkadia.org/drepper/tls.pdf) but it is a few years old and > > > covers only a subset of architectures. > > > > > > Is TLS supported on all architectures in GCC? > > > > > > Is there some documentation on how it is implemented on architectures not > > > in Ulrich's paper? Or some guidance on how to extract this information > > from > > > the GCC source? > > > > The ARM (32) abi has some extensions to that, which originally came from > > Alex Oliva and then I implemented (The GNU2 TLS stuff). I think the > > smarts is in the linker for that though. > > > > IMHO bfd might be a better source of information than gcc. > > > > BFD would know the section and attribute part but isn't gcc responsible for > generating the code to dereference into it? It could be a specific base > register > or an invalid instruction fault (MIPS) or something else. I'm wondering how > one knows what that magic to look up the base is for a specific > architecture. > > Or if there is an easy way for a target to change say the MIPS bad > instruction > to a subroutine call? It would seem that GCC would have an architecture > independent base lookup alternative.
NOTE MIPS32/64r3 says that system register is implemented. I know of a few implementations that implement that register as a register (Octeon 2 and Octeon3 for an example). Thanks, Andrew > > --joel > > --joel > > > > > natan > > -- > > Nathan Sidwell > >
