I checked the shared library and parts of it are not compiled with -fpic. So that could be the cause of the problematic TLS behavior I'm seeing? The run-time linker doesn't prepare the loaded TLS variables correctly? Can -fpic compilation cause significant performance or memory footprint changes on modern x86 Xeon processors? Thanks for the help, Saul On Wed, Jan 16, 2013 at 6:29 PM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > On Wed, Jan 16, 2013 at 3:17 PM, Saul Tamari <stamari@xxxxxxxxx> wrote: >> >> I'm using a GNU/Linux on an Intel 32bit x86. >> >> I think that I might be digging too deep. There shouldn't be any >> problem with the gs segment or whatever it points to. >> >> The application is a C program that dynamically loads (using dlopen()) >> C++ libraries. >> Do I need to set -ftls-model=global-dynamic when compiling the various >> C++ libraries so TLS works correctly? > > Normally that will happen automatically when you use -fPIC. Since you > are using 32-bit x86, I guess it is possible that you are compiling > code without -fPIC and then putting it in a shared library and then > using dlopen. If so, that is your problem; use -fPIC. > > If you are using -fPIC, then I do not know what is wrong. > >> Now in order to get eax's value before the call to ___tls_get_attr() I do: >> 0xf6f536d9 + 0x3591b = 0xf6f88ff4 >> 0xf6f88ff4 - 0x56c = 0xf6f88a88 >> >> Can this value help me locate which tls value is accessed here? Can I >> find it with readelf or objdump? > > I don't know of any easy way to from that address to the variable > being accessed. > > By looking at the source code for __cxa_get_globals (which is part of > GCC, not glibc) I can tell you that the variable in question is a > static __thread variable defined in > libstdc++-v3/libsupc++/eh_globals.cc. The variabls is used to keep > track of all the C++ exceptions currently being thrown. > > Ian
