Finding the source code for ___tls_get_addr_internal()

Finding the source code for ___tls_get_addr_internal()

[Saul Tamari]

Hi,

I'm debugging some C++ application which crashed with a segmentation
fault caused by trying to access address 0xc.
After some digging I learned that the crash happened in
__cxa_allocate_exception() in the following code:
__cxa_eh_globals *globals = __cxa_get_globals ();
globals->uncaughtExceptions += 1;           <-- this tries to
increment the word at address 0xc -    addl  $0x1,0x4(%eax)

Checking __cxa_get_globals() shows that it calls ___tls_get_addr@plt
which in turn jumps to ___tls_get_addr_internal which returns 0x8 in
eax.
I suspect the cause of this wrong return value is with some issue
related to the gs descriptor but I have no proof about that.

Is ___tls_get_addr_internal() compiled from C source code or is it
generated directly in assembly code?
Where can I find the C source code that was used to generate
___tls_get_addr_internal ?

The compiler used was g++4.4.6

Thanks,
Saul


(gdb) disas 0xf7f1dd50
Dump of assembler code for function ___tls_get_addr_internal:
0xf7f1dd50 <___tls_get_addr_internal+0>:
       push   %ebp
0xf7f1dd51 <___tls_get_addr_internal+1>:        mov    %esp,%ebp
0xf7f1dd53 <___tls_get_addr_internal+3>:        sub    $0x28,%esp
0xf7f1dd56 <___tls_get_addr_internal+6>:        mov    %ebx,-0xc(%ebp)
0xf7f1dd59 <___tls_get_addr_internal+9>:        mov    %esi,-0x8(%ebp)
0xf7f1dd5c <___tls_get_addr_internal+12>:       mov    %eax,%esi
0xf7f1dd5e <___tls_get_addr_internal+14>:       mov    %edi,-0x4(%ebp)
0xf7f1dd61 <___tls_get_addr_internal+17>:       call   0xf7f22feb
<__i686.get_pc_thunk.bx>
0xf7f1dd66 <___tls_get_addr_internal+22>:       add    $0xb25a,%ebx
0xf7f1dd6c <___tls_get_addr_internal+28>:       mov    %gs:0x4,%eax
0xf7f1dd72 <___tls_get_addr_internal+34>:       mov    (%eax),%edx
0xf7f1dd74 <___tls_get_addr_internal+36>:       cmp    0x5dc(%ebx),%edx
0xf7f1dd7a <___tls_get_addr_internal+42>:       mov    %eax,-0x18(%ebp)
0xf7f1dd7d <___tls_get_addr_internal+45>:       movl   $0x0,-0x14(%ebp)
0xf7f1dd84 <___tls_get_addr_internal+52>:       jne    0xf7f1dda7
<___tls_get_addr_internal+87>
0xf7f1dd86 <___tls_get_addr_internal+54>:       mov    (%esi),%edx
0xf7f1dd88 <___tls_get_addr_internal+56>:       lea    (%eax,%edx,8),%eax
0xf7f1dd8b <___tls_get_addr_internal+59>:       mov    %eax,-0x1c(%ebp)
0xf7f1dd8e <___tls_get_addr_internal+62>:       mov    (%eax),%edi
0xf7f1dd90 <___tls_get_addr_internal+64>:       cmp    $0xffffffff,%edi
0xf7f1dd93 <___tls_get_addr_internal+67>:       je     0xf7f1ddbf
<___tls_get_addr_internal+111>
0xf7f1dd95 <___tls_get_addr_internal+69>:       add    0x4(%esi),%edi
0xf7f1dd98 <___tls_get_addr_internal+72>:       mov    -0xc(%ebp),%ebx
0xf7f1dd9b <___tls_get_addr_internal+75>:       mov    -0x8(%ebp),%esi
0xf7f1dd9e <___tls_get_addr_internal+78>:       mov    %edi,%eax
0xf7f1dda0 <___tls_get_addr_internal+80>:       mov    -0x4(%ebp),%edi
0xf7f1dda3 <___tls_get_addr_internal+83>:       mov    %ebp,%esp
0xf7f1dda5 <___tls_get_addr_internal+85>:       pop    %ebp
0xf7f1dda6 <___tls_get_addr_internal+86>:       ret
0xf7f1dda7 <___tls_get_addr_internal+87>:       mov    (%esi),%eax
0xf7f1dda9 <___tls_get_addr_internal+89>:       mov    %eax,(%esp)
0xf7f1ddac <___tls_get_addr_internal+92>:       call   0xf7f1daf0
<_dl_update_slotinfo>
0xf7f1ddb1 <___tls_get_addr_internal+97>:       mov    %eax,-0x14(%ebp)
0xf7f1ddb4 <___tls_get_addr_internal+100>:      mov    %gs:0x4,%eax
0xf7f1ddba <___tls_get_addr_internal+106>:      mov    %eax,-0x18(%ebp)
0xf7f1ddbd <___tls_get_addr_internal+109>:      jmp    0xf7f1dd86
<___tls_get_addr_internal+54>
0xf7f1ddbf <___tls_get_addr_internal+111>:      mov    -0x14(%ebp),%edi
0xf7f1ddc2 <___tls_get_addr_internal+114>:      test   %edi,%edi
0xf7f1ddc4 <___tls_get_addr_internal+116>:      je     0xf7f1de3f
<___tls_get_addr_internal+239>
0xf7f1ddc6 <___tls_get_addr_internal+118>:      mov    -0x14(%ebp),%edx
0xf7f1ddc9 <___tls_get_addr_internal+121>:      mov    0x230(%edx),%eax
0xf7f1ddcf <___tls_get_addr_internal+127>:      mov    %eax,0x4(%esp)
0xf7f1ddd3 <___tls_get_addr_internal+131>:      mov    0x234(%edx),%eax
0xf7f1ddd9 <___tls_get_addr_internal+137>:      mov    %eax,(%esp)
0xf7f1dddc <___tls_get_addr_internal+140>:      call   0xf7f0d798
<__libc_memalign@plt>
0xf7f1dde1 <___tls_get_addr_internal+145>:      test   %eax,%eax
0xf7f1dde3 <___tls_get_addr_internal+147>:      mov    %eax,%edi
0xf7f1dde5 <___tls_get_addr_internal+149>:      je     0xf7f1de64
<___tls_get_addr_internal+276>
0xf7f1dde7 <___tls_get_addr_internal+151>:      mov    -0x14(%ebp),%edx
0xf7f1ddea <___tls_get_addr_internal+154>:      mov    0x22c(%edx),%eax
0xf7f1ddf0 <___tls_get_addr_internal+160>:      mov    0x230(%edx),%edx
0xf7f1ddf6 <___tls_get_addr_internal+166>:      mov    %eax,0x8(%esp)
0xf7f1ddfa <___tls_get_addr_internal+170>:      sub    %eax,%edx
0xf7f1ddfc <___tls_get_addr_internal+172>:      mov    %edx,-0x10(%ebp)
0xf7f1ddff <___tls_get_addr_internal+175>:      mov    -0x14(%ebp),%edx
0xf7f1de02 <___tls_get_addr_internal+178>:      mov    0x228(%edx),%eax
0xf7f1de08 <___tls_get_addr_internal+184>:      mov    %edi,(%esp)
0xf7f1de0b <___tls_get_addr_internal+187>:      mov    %eax,0x4(%esp)
0xf7f1de0f <___tls_get_addr_internal+191>:      call   0xf7f22e30 <mempcpy>
0xf7f1de14 <___tls_get_addr_internal+196>:      mov    -0x10(%ebp),%edx
0xf7f1de17 <___tls_get_addr_internal+199>:      movl   $0x0,0x4(%esp)
0xf7f1de1f <___tls_get_addr_internal+207>:      mov    %edx,0x8(%esp)
0xf7f1de23 <___tls_get_addr_internal+211>:      mov    %eax,(%esp)
0xf7f1de26 <___tls_get_addr_internal+214>:      call   0xf7f22de0 <memset>
0xf7f1de2b <___tls_get_addr_internal+219>:      mov    -0x1c(%ebp),%eax
0xf7f1de2e <___tls_get_addr_internal+222>:      mov    %edi,(%eax)
0xf7f1de30 <___tls_get_addr_internal+224>:      mov    (%esi),%eax
0xf7f1de32 <___tls_get_addr_internal+226>:      mov    -0x18(%ebp),%edx
0xf7f1de35 <___tls_get_addr_internal+229>:      movb   $0x0,0x4(%edx,%eax,8)
0xf7f1de3a <___tls_get_addr_internal+234>:      jmp    0xf7f1dd95
<___tls_get_addr_internal+69>
0xf7f1de3f <___tls_get_addr_internal+239>:      mov    0x5c4(%ebx),%edi
0xf7f1de45 <___tls_get_addr_internal+245>:      mov    %edx,%eax
0xf7f1de47 <___tls_get_addr_internal+247>:      mov    (%edi),%ecx
0xf7f1de49 <___tls_get_addr_internal+249>:      cmp    %ecx,%edx
0xf7f1de4b <___tls_get_addr_internal+251>:      jb     0xf7f1de58
<___tls_get_addr_internal+264>
0xf7f1de4d <___tls_get_addr_internal+253>:      mov    0x4(%edi),%edi
0xf7f1de50 <___tls_get_addr_internal+256>:      sub    %ecx,%eax
0xf7f1de52 <___tls_get_addr_internal+258>:      mov    (%edi),%ecx
0xf7f1de54 <___tls_get_addr_internal+260>:      cmp    %eax,%ecx
0xf7f1de56 <___tls_get_addr_internal+262>:      jbe    0xf7f1de4d
<___tls_get_addr_internal+253>
0xf7f1de58 <___tls_get_addr_internal+264>:      mov    0xc(%edi,%eax,8),%eax
0xf7f1de5c <___tls_get_addr_internal+268>:      mov    %eax,-0x14(%ebp)
0xf7f1de5f <___tls_get_addr_internal+271>:      jmp    0xf7f1ddc6
<___tls_get_addr_internal+118>
0xf7f1de64 <___tls_get_addr_internal+276>:      lea    -0x3584(%ebx),%eax
0xf7f1de6a <___tls_get_addr_internal+282>:      mov    %eax,0x4(%esp)
0xf7f1de6e <___tls_get_addr_internal+286>:      movl   $0x2,(%esp)
0xf7f1de75 <___tls_get_addr_internal+293>:      call   0xf7f1bfd0 <_dl_dprintf>
0xf7f1de7a <___tls_get_addr_internal+298>:      movl   $0x7f,(%esp)
0xf7f1de81 <___tls_get_addr_internal+305>:      call   0xf7f226f4 <_exit>

Re: Finding the source code for ___tls_get_addr_internal()

[Ian Lance Taylor]

On Wed, Jan 16, 2013 at 12:08 PM, Saul Tamari <stamari@gmail.com> wrote:
>
> Is ___tls_get_addr_internal() compiled from C source code or is it
> generated directly in assembly code?
> Where can I find the C source code that was used to generate
> ___tls_get_addr_internal ?

__tls_get_addr is provided by your C library.  I don't think you
mentioned what system you are using, but if it is a GNU/Linux system
then __tls_get_addr defined by glibc.  I'm not sure quite where
__tls_get_addr_internal comes in.  __tls_get_addr is defined in
elf/dl-tls.c in the glibc sources.  You seem to be using 32-bit x86;
the interesting 32-bit x86 code is in nptl/sysdeps/i386/tls.h.

It does indeed use %gs.  You can't change %gs yourself if your program
uses TLS variables.

Ian

Re: Finding the source code for ___tls_get_addr_internal()

[Saul Tamari]

Hi,

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?


(gdb) disas __cxa_get_globals
Dump of assembler code for function __cxa_get_globals:
0xf6f536d0 <__cxa_get_globals+0>:       push   %ebp
0xf6f536d1 <__cxa_get_globals+1>:       mov    %esp,%ebp
0xf6f536d3 <__cxa_get_globals+3>:       push   %ebx
0xf6f536d4 <__cxa_get_globals+4>:       call   0xf6ee8f07 <pthread_join+247>
0xf6f536d9 <__cxa_get_globals+9>:       add    $0x3591b,%ebx
0xf6f536df <__cxa_get_globals+15>:      lea    -0x56c(,%ebx,1),%eax
0xf6f536e6 <__cxa_get_globals+22>:      call   0xf6ee7730 <___tls_get_addr@plt>
0xf6f536eb <__cxa_get_globals+27>:      pop    %ebx
0xf6f536ec <__cxa_get_globals+28>:      pop    %ebp
0xf6f536ed <__cxa_get_globals+29>:      ret

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?


Thanks,
Saul



On Wed, Jan 16, 2013 at 5:59 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Wed, Jan 16, 2013 at 12:08 PM, Saul Tamari <stamari@gmail.com> wrote:
>>
>> Is ___tls_get_addr_internal() compiled from C source code or is it
>> generated directly in assembly code?
>> Where can I find the C source code that was used to generate
>> ___tls_get_addr_internal ?
>
> __tls_get_addr is provided by your C library.  I don't think you
> mentioned what system you are using, but if it is a GNU/Linux system
> then __tls_get_addr defined by glibc.  I'm not sure quite where
> __tls_get_addr_internal comes in.  __tls_get_addr is defined in
> elf/dl-tls.c in the glibc sources.  You seem to be using 32-bit x86;
> the interesting 32-bit x86 code is in nptl/sysdeps/i386/tls.h.
>
> It does indeed use %gs.  You can't change %gs yourself if your program
> uses TLS variables.
>
> Ian

Re: Finding the source code for ___tls_get_addr_internal()

[Ian Lance Taylor]

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

Re: Finding the source code for ___tls_get_addr_internal()

[Saul Tamari]

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

Re: Finding the source code for ___tls_get_addr_internal()

[Ian Lance Taylor]

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

If you put code that accesses TLS variables into a shared library, and
that code was not compiled with -fpic/-fPIC nor with
-ftls-model=global-dynamic, then accessing the TLS variables will read
the wrong values.

> Can -fpic compilation cause significant performance or memory
> footprint changes on modern x86 Xeon processors?

Yes, it's about a 3 or 4% performance hit.  Putting code not compiled
with -fPIC in a shared library will slow down program startup, and
make the program less secure because the text segment will be
writable.  Also, the shared library will not actually be shared: each
process will have its own copy in virtual memory.  Whether these
things matter to you depends on how you run your code.

Ian

Re: Finding the source code for ___tls_get_addr_internal()

[Saul Tamari]

On Thu, Jan 17, 2013 at 12:07 AM, Ian Lance Taylor <iant@google.com> wrote:
> If you put code that accesses TLS variables into a shared library, and
> that code was not compiled with -fpic/-fPIC nor with
> -ftls-model=global-dynamic, then accessing the TLS variables will read
> the wrong values.

Is there a way to verify if there are wrongly initialized TLS
variables in some application or I can only detect such cases when the
application fails?
Can the linker or runtime linker warn about these cases? Or because we
haven't compiled with -fpic or -ftls-model=global-dynamic, then the
runtime linker doesn't know there are TLS variables in our binary?

Thanks,
Saul

Re: Finding the source code for ___tls_get_addr_internal()

[Ian Lance Taylor]

On Thu, Jan 17, 2013 at 2:11 PM, Saul Tamari <stamari@gmail.com> wrote:
> On Thu, Jan 17, 2013 at 12:07 AM, Ian Lance Taylor <iant@google.com> wrote:
>> If you put code that accesses TLS variables into a shared library, and
>> that code was not compiled with -fpic/-fPIC nor with
>> -ftls-model=global-dynamic, then accessing the TLS variables will read
>> the wrong values.
>
> Is there a way to verify if there are wrongly initialized TLS
> variables in some application or I can only detect such cases when the
> application fails?

You could probably look at the dynamic relocations and see if there
are any TLS relocations in the shared library that are not global
dynamic.

> Can the linker or runtime linker warn about these cases? Or because we
> haven't compiled with -fpic or -ftls-model=global-dynamic, then the
> runtime linker doesn't know there are TLS variables in our binary?

I think the linker (ld) could warn about this case.

Ian

Re: Finding the source code for ___tls_get_addr_internal()

[Saul Tamari]

On Fri, Jan 18, 2013 at 12:43 AM, Ian Lance Taylor <iant@google.com> wrote:
>
> On Thu, Jan 17, 2013 at 2:11 PM, Saul Tamari <stamari@gmail.com> wrote:
> > Is there a way to verify if there are wrongly initialized TLS
> > variables in some application or I can only detect such cases when the
> > application fails?
>
> You could probably look at the dynamic relocations and see if there
> are any TLS relocations in the shared library that are not global
> dynamic.


I tried the following:
[root@vm0 ~]# readelf -s ./mylib.so | grep TLS
   808: 00000418     4 TLS     GLOBAL DEFAULT   16 _ZN24MonitorWorkItemOpera
   914: 00000008     4 TLS     GLOBAL DEFAULT   16 _ZN12TQQQScheduler9_instan
  1176: 00000414     4 TLS     GLOBAL DEFAULT   16 time_monitor_list
  2577: 00000000     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
  2788: 00000004     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
   249: 0000000c     4 TLS     LOCAL  DEFAULT   16 _ZL17pthread_qqq_owner
   435: 00000010     1 TLS     LOCAL  DEFAULT   16 _ZL11g_in_syslog
   436: 00000011  1024 TLS     LOCAL  DEFAULT   16 _ZL9g_tls_buf
  2230: 00000418     4 TLS     GLOBAL DEFAULT   16 _ZN24MonitorWorkItemOpera
  2467: 00000000     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
  3375: 00000008     4 TLS     GLOBAL DEFAULT   16 _ZN12QQQScheduler9_instan
  3660: 00000414     4 TLS     GLOBAL DEFAULT   16 time_monitor_list
  3766: 00000004     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli

So I see several TLS entries reported as WEAK and LOCAL and they could
cause the TLS issues I was experiencing?

I should probably read your blog to get a better understanding of this.

Thanks,
Saul

Re: Finding the source code for ___tls_get_addr_internal()

[Ian Lance Taylor]

On Fri, Jan 18, 2013 at 5:31 AM, Saul Tamari <stamari@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 12:43 AM, Ian Lance Taylor <iant@google.com> wrote:
>>
>> On Thu, Jan 17, 2013 at 2:11 PM, Saul Tamari <stamari@gmail.com> wrote:
>> > Is there a way to verify if there are wrongly initialized TLS
>> > variables in some application or I can only detect such cases when the
>> > application fails?
>>
>> You could probably look at the dynamic relocations and see if there
>> are any TLS relocations in the shared library that are not global
>> dynamic.
>
>
> I tried the following:
> [root@vm0 ~]# readelf -s ./mylib.so | grep TLS
>    808: 00000418     4 TLS     GLOBAL DEFAULT   16 _ZN24MonitorWorkItemOpera
>    914: 00000008     4 TLS     GLOBAL DEFAULT   16 _ZN12TQQQScheduler9_instan
>   1176: 00000414     4 TLS     GLOBAL DEFAULT   16 time_monitor_list
>   2577: 00000000     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>   2788: 00000004     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>    249: 0000000c     4 TLS     LOCAL  DEFAULT   16 _ZL17pthread_qqq_owner
>    435: 00000010     1 TLS     LOCAL  DEFAULT   16 _ZL11g_in_syslog
>    436: 00000011  1024 TLS     LOCAL  DEFAULT   16 _ZL9g_tls_buf
>   2230: 00000418     4 TLS     GLOBAL DEFAULT   16 _ZN24MonitorWorkItemOpera
>   2467: 00000000     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>   3375: 00000008     4 TLS     GLOBAL DEFAULT   16 _ZN12QQQScheduler9_instan
>   3660: 00000414     4 TLS     GLOBAL DEFAULT   16 time_monitor_list
>   3766: 00000004     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>
> So I see several TLS entries reported as WEAK and LOCAL and they could
> cause the TLS issues I was experiencing?

Those are the symbols.  The issue here is the relocations, displayed
by readelf -r.  Dynamic and non-dynamic references to TLS symbols use
different relocations.

Ian

Re: Finding the source code for ___tls_get_addr_internal()

[Saul Tamari]

Ok,

So I understood from you that I need to look for R_386_TLS_GD and/or
R_386_TLS_LDM in my library after I compile it with -fpic or
-ftls-model=global-dynamic.

In a previous post you said "Putting code not compiled with -fPIC in a
shared library will slow down program startup, and make the program
less secure because the text segment will be writable."
Now, If I decide to use -ftls-model, instead of -fpic, is there a way
to set the library's text segments read-only like I was using -fpic?

Thanks,
Saul




On Fri, Jan 18, 2013 at 7:46 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Fri, Jan 18, 2013 at 5:31 AM, Saul Tamari <stamari@gmail.com> wrote:
>> On Fri, Jan 18, 2013 at 12:43 AM, Ian Lance Taylor <iant@google.com> wrote:
>>>
>>> On Thu, Jan 17, 2013 at 2:11 PM, Saul Tamari <stamari@gmail.com> wrote:
>>> > Is there a way to verify if there are wrongly initialized TLS
>>> > variables in some application or I can only detect such cases when the
>>> > application fails?
>>>
>>> You could probably look at the dynamic relocations and see if there
>>> are any TLS relocations in the shared library that are not global
>>> dynamic.
>>
>>
>> I tried the following:
>> [root@vm0 ~]# readelf -s ./mylib.so | grep TLS
>>    808: 00000418     4 TLS     GLOBAL DEFAULT   16 _ZN24MonitorWorkItemOpera
>>    914: 00000008     4 TLS     GLOBAL DEFAULT   16 _ZN12TQQQScheduler9_instan
>>   1176: 00000414     4 TLS     GLOBAL DEFAULT   16 time_monitor_list
>>   2577: 00000000     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>>   2788: 00000004     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>>    249: 0000000c     4 TLS     LOCAL  DEFAULT   16 _ZL17pthread_qqq_owner
>>    435: 00000010     1 TLS     LOCAL  DEFAULT   16 _ZL11g_in_syslog
>>    436: 00000011  1024 TLS     LOCAL  DEFAULT   16 _ZL9g_tls_buf
>>   2230: 00000418     4 TLS     GLOBAL DEFAULT   16 _ZN24MonitorWorkItemOpera
>>   2467: 00000000     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>>   3375: 00000008     4 TLS     GLOBAL DEFAULT   16 _ZN12QQQScheduler9_instan
>>   3660: 00000414     4 TLS     GLOBAL DEFAULT   16 time_monitor_list
>>   3766: 00000004     4 TLS     WEAK   DEFAULT   16 _ZZN6Remote23MultiplexCli
>>
>> So I see several TLS entries reported as WEAK and LOCAL and they could
>> cause the TLS issues I was experiencing?
>
> Those are the symbols.  The issue here is the relocations, displayed
> by readelf -r.  Dynamic and non-dynamic references to TLS symbols use
> different relocations.
>
> Ian

Re: Finding the source code for ___tls_get_addr_internal()

[Ian Lance Taylor]

On Sun, Jan 20, 2013 at 8:43 AM, Saul Tamari <stamari@gmail.com> wrote:
>
> In a previous post you said "Putting code not compiled with -fPIC in a
> shared library will slow down program startup, and make the program
> less secure because the text segment will be writable."
> Now, If I decide to use -ftls-model, instead of -fpic, is there a way
> to set the library's text segments read-only like I was using -fpic?

No.  If you put code compiled without -fpic into a shared library, the
text segments will not be read-only at program startup time.

Ian