Hello Nikhil,
Just to add some more references you might like to check out, although be warned they are not easy to digest. They do go into how the memory for thread local storage is allocated so you may be able to skip through the details.
There shouldn't be anything special that you need to do to make this work on the command line. The global-dynamic model is the most general and can cope with libraries that are dynamically loaded via dlopen. The static linker is able to perform relaxations when it can detect that the full generality of global-dynamic is not needed.
It is difficult to know whether your program has segfaulted due to the program loader not allocating memory for the thread local storage block, or for the toolchain to have miscompiled code to access the memory. As Kugan suggests you'll need to provide some kind of reproducer before we'll be able to help.
Hope this is of some help
Peter
References: For 32-bit ARM the Addenda to the ABI for the ARM Architecture has a good introduction to how the traditional model of TLS model works. This is available at: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045e/IHI0045E_ABI_adden...
Since that document was published an alternative descriptor model of TLS has been adopted. This is less formally documented, the best reference I have found are: http://sourcery.mentor.com/public/publications/RFC-TLSDESC-ARM.txt for ARM details and http://www.fsfla.org/~lxoliva/writeups/TLS/paper-lk2006.pdf for a general overview.
There is very little public information about the details of the AARCH64 TLS although it differs from ARM only in the low-level details such as the instructions used.
On 17 May 2016 at 21:58, Bill Fischofer bill.fischofer@linaro.org wrote:
This may be a better question for the linaro tools group. +cc their list for the general question of conventions surrounding how shared library objects identify and access thread-local storage that they need as part of calling threads.
On Tue, May 17, 2016 at 11:06 AM, Nikhil Agarwal nikhil.agarwal@linaro.org wrote:
Hi All,
I am trying to write a shared library object over ODP. Our ODP library has some per thread variables. When my application invokes an API of shared object which accesses per thread variable it gives segmentation fault.
My concern is that when a shared object is loaded dynamically, how memory is assigned to thread specific variables defined inside shared objects. AFAIK we need to compile it with -ftls-model=global-dynamic, which is enabled by default when compiled with -fPIC flag, and library loader takes care for these issues.
I am not an expert in this area, please help me in getting to some suitable reference pointers or some steps I might have missed.
Thanks in advance
Nikhil
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain