Re: Finding the source code for ___tls_get_addr_internal()

[Saul Tamari <stamari at gmail dot com>]

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@google.com> wrote:
> On Wed, Jan 16, 2013 at 3:17 PM, Saul Tamari <stamari@gmail.com> 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