* Avoid privatization of TLS variables @ 2014-09-20 3:16 Jan Hubicka 2014-09-24 17:53 ` Markus Trippelsdorf 0 siblings, 1 reply; 20+ messages in thread From: Jan Hubicka @ 2014-09-20 3:16 UTC (permalink / raw) To: gcc-patches Hi, libreoffice fails to build with TLS because of "Cannot load any more object with static TLS". Iant pointed out to me the difference that the initial exec TLS model is also used by static TLS variables. This patch prevents turning TLS variables into static that lets me to finish libreoffice build. Can the conditional be strenghtened somewhat? decl_default_tls_model has: if (!flag_shlib) { if (is_local) kind = TLS_MODEL_LOCAL_EXEC; else kind = TLS_MODEL_INITIAL_EXEC; } /* Local dynamic is inefficient when we're not combining the parts of the address. */ else if (optimize && is_local) kind = TLS_MODEL_LOCAL_DYNAMIC; else kind = TLS_MODEL_GLOBAL_DYNAMIC; perhaps we should have fake TLS_MODEL_EXEC and TLS_MODE_DYNAMIC modes that get more specified later once the visibility is finalized instead of deciding it at compile time? Bootstrapped/regtested x86_64-linux, comitted for now until we get better solution (if it exists). Honza Index: ChangeLog =================================================================== --- ChangeLog (revision 215416) +++ ChangeLog (working copy) @@ -1,5 +1,10 @@ 2014-09-19 Jan Hubicka <hubicka@ucw.cz> + * ipa-visibility.c (varpool_node::externally_visible_p): Do not + privatize dynamic TLS variables. + +2014-09-19 Jan Hubicka <hubicka@ucw.cz> + * diagnostic.c (warning_n): New function. * diagnostic-core.h (warning_n): Declare. * ipa-devirt.c (ipa_devirt): Handle singulars correctly; Index: ipa-visibility.c =================================================================== --- ipa-visibility.c (revision 215415) +++ ipa-visibility.c (working copy) @@ -277,6 +277,13 @@ varpool_node::externally_visible_p (void if (used_from_object_file_p ()) return true; + /* Bringing TLS variables local may cause dynamic linker failures + on limits of static TLS vars. */ + if (DECL_THREAD_LOCAL_P (decl) + && (DECL_TLS_MODEL (decl) != TLS_MODEL_EMULATED + && DECL_TLS_MODEL (decl) != TLS_MODEL_INITIAL_EXEC)) + return true; + if (DECL_HARD_REGISTER (decl)) return true; if (DECL_PRESERVE_P (decl)) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-20 3:16 Avoid privatization of TLS variables Jan Hubicka @ 2014-09-24 17:53 ` Markus Trippelsdorf 2014-09-24 18:18 ` Jan Hubicka 0 siblings, 1 reply; 20+ messages in thread From: Markus Trippelsdorf @ 2014-09-24 17:53 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote: > Hi, > libreoffice fails to build with TLS because of "Cannot load any more object > with static TLS". Iant pointed out to me the difference that the initial exec > TLS model is also used by static TLS variables. > > This patch prevents turning TLS variables into static that lets me to finish > libreoffice build. This patch triggers an assert in gold: ~ % echo "int main () {}" | g++ -flto -fprofile-generate -x c++ - ld: internal error in relocate_tls, at/gold/x86_64.cc:3829 collect2: error: ld returned 1 exit status ld.bfd works fine. -- Markus ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-24 17:53 ` Markus Trippelsdorf @ 2014-09-24 18:18 ` Jan Hubicka 2014-09-24 19:10 ` Markus Trippelsdorf 2014-09-25 0:48 ` Ian Lance Taylor 0 siblings, 2 replies; 20+ messages in thread From: Jan Hubicka @ 2014-09-24 18:18 UTC (permalink / raw) To: Markus Trippelsdorf, ian; +Cc: Jan Hubicka, gcc-patches > On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote: > > Hi, > > libreoffice fails to build with TLS because of "Cannot load any more object > > with static TLS". Iant pointed out to me the difference that the initial exec > > TLS model is also used by static TLS variables. > > > > This patch prevents turning TLS variables into static that lets me to finish > > libreoffice build. > > This patch triggers an assert in gold: > > ~ % echo "int main () {}" | g++ -flto -fprofile-generate -x c++ - > ld: internal error in relocate_tls, at/gold/x86_64.cc:3829 > collect2: error: ld returned 1 exit status I saw this error, too, just not with such a simple testcase :) Ian, I think this is bug in gold. What does the assert mean? Honza > > ld.bfd works fine. > > -- > Markus ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-24 18:18 ` Jan Hubicka @ 2014-09-24 19:10 ` Markus Trippelsdorf 2014-09-25 0:48 ` Ian Lance Taylor 1 sibling, 0 replies; 20+ messages in thread From: Markus Trippelsdorf @ 2014-09-24 19:10 UTC (permalink / raw) To: Jan Hubicka; +Cc: ian, gcc-patches On 2014.09.24 at 20:18 +0200, Jan Hubicka wrote: > > On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote: > > > Hi, > > > libreoffice fails to build with TLS because of "Cannot load any more object > > > with static TLS". Iant pointed out to me the difference that the initial exec > > > TLS model is also used by static TLS variables. > > > > > > This patch prevents turning TLS variables into static that lets me to finish > > > libreoffice build. > > > > This patch triggers an assert in gold: > > > > ~ % echo "int main () {}" | g++ -flto -fprofile-generate -x c++ - > > ld: internal error in relocate_tls, at/gold/x86_64.cc:3829 > > collect2: error: ld returned 1 exit status > > I saw this error, too, just not with such a simple testcase :) > Ian, I think this is bug in gold. What does the assert mean? I've opened: https://sourceware.org/bugzilla/show_bug.cgi?id=17432 -- Markus ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-24 18:18 ` Jan Hubicka 2014-09-24 19:10 ` Markus Trippelsdorf @ 2014-09-25 0:48 ` Ian Lance Taylor 2014-09-25 1:58 ` Jan Hubicka 2014-09-27 7:56 ` Andrew Haley 1 sibling, 2 replies; 20+ messages in thread From: Ian Lance Taylor @ 2014-09-25 0:48 UTC (permalink / raw) To: Jan Hubicka; +Cc: Markus Trippelsdorf, Ian Lance Taylor, gcc-patches On Wed, Sep 24, 2014 at 11:18 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote: >> > Hi, >> > libreoffice fails to build with TLS because of "Cannot load any more object >> > with static TLS". Iant pointed out to me the difference that the initial exec >> > TLS model is also used by static TLS variables. >> > >> > This patch prevents turning TLS variables into static that lets me to finish >> > libreoffice build. >> >> This patch triggers an assert in gold: >> >> ~ % echo "int main () {}" | g++ -flto -fprofile-generate -x c++ - >> ld: internal error in relocate_tls, at/gold/x86_64.cc:3829 >> collect2: error: ld returned 1 exit status > > I saw this error, too, just not with such a simple testcase :) > Ian, I think this is bug in gold. What does the assert mean? I'm not sure because my line numbers don't match. If it is this assert: case elfcpp::R_X86_64_TPOFF32: // Local-exec if (tls_segment == NULL) { gold_assert(parameters->errors()->error_count() > 0 || issue_undefined_symbol_error(gsym)); return; } value -= tls_segment->memsz(); Relocate_functions<size, false>::rela32(view, value, addend); break; then the problem is that there is a TPOFF32 relocation but none of the input files has a section with the SHF_TLS flag set. This should not be possible--the TPOFF32 relocation implies a TLS variable, but the absence of any SHF_TLS sections implies that there are no TLS variables. Why would there be a TPOFF32 relocation in the simple test case from Markus? If that is not the assertion, let me know what is. Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 0:48 ` Ian Lance Taylor @ 2014-09-25 1:58 ` Jan Hubicka 2014-09-25 15:24 ` Ian Lance Taylor 2014-09-27 7:56 ` Andrew Haley 1 sibling, 1 reply; 20+ messages in thread From: Jan Hubicka @ 2014-09-25 1:58 UTC (permalink / raw) To: Ian Lance Taylor Cc: Jan Hubicka, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches [-- Attachment #1: Type: text/plain, Size: 4670 bytes --] > > I'm not sure because my line numbers don't match. If it is this > assert: > > case elfcpp::R_X86_64_TPOFF32: // Local-exec > if (tls_segment == NULL) > { > gold_assert(parameters->errors()->error_count() > 0 > || issue_undefined_symbol_error(gsym)); > return; > } > value -= tls_segment->memsz(); > Relocate_functions<size, false>::rela32(view, value, addend); > break; I looked it up and it was the place I got ICE, too. > > then the problem is that there is a TPOFF32 relocation but none of the > input files has a section with the SHF_TLS flag set. This should not > be possible--the TPOFF32 relocation implies a TLS variable, but the > absence of any SHF_TLS sections implies that there are no TLS > variables. I get: a.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <main>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 64 48 8b 04 25 00 00 mov %fs:0x0,%rax b: 00 00 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv d: 64 48 8b 14 25 00 00 mov %fs:0x0,%rdx 14: 00 00 12: R_X86_64_TPOFF32 __gcov_indirect_call_callee_ltopriv 16: 48 89 d1 mov %rdx,%rcx 19: ba 00 00 00 00 mov $0x0,%edx 1a: R_X86_64_32 main 1e: be eb 72 70 06 mov $0x67072eb,%esi 23: 48 89 c7 mov %rax,%rdi 26: e8 00 00 00 00 callq 2b <main+0x2b> 27: R_X86_64_PC32 __gcov_indirect_call_profiler+0xfffffffffffffffc 2b: 64 48 c7 04 25 00 00 movq $0x0,%fs:0x0 32: 00 00 00 00 00 00 30: R_X86_64_TPOFF32 __gcov_indirect_call_callee_ltopriv 38: bf 00 00 00 00 mov $0x0,%edi 39: R_X86_64_32 .bss+0x8 3d: e8 00 00 00 00 callq 42 <main+0x42> 3e: R_X86_64_PC32 __gcov_time_profiler+0xfffffffffffffffc 42: ba 00 00 00 00 mov $0x0,%edx 47: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 4e <main+0x4e> 4a: R_X86_64_PC32 .bss+0xfffffffffffffffc 4e: 48 83 c0 01 add $0x1,%rax 52: 48 89 05 00 00 00 00 mov %rax,0x0(%rip) # 59 <main+0x59> 55: R_X86_64_PC32 .bss+0xfffffffffffffffc 59: 89 d0 mov %edx,%eax 5b: 5d pop %rbp 5c: c3 retq 000000000000005d <_GLOBAL__sub_I_65535_0_main>: 5d: 55 push %rbp 5e: 48 89 e5 mov %rsp,%rbp 61: bf 00 00 00 00 mov $0x0,%edi 62: R_X86_64_32 .data+0x40 66: e8 00 00 00 00 callq 6b <_GLOBAL__sub_I_65535_0_main+0xe> 67: R_X86_64_PC32 __gcov_init+0xfffffffffffffffc 6b: 5d pop %rbp 6c: c3 retq and in asm: .file "ccstYwxO.ltrans0.o" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movq %fs:__gcov_indirect_call_counters_ltopriv@tpoff, %rax movq %fs:__gcov_indirect_call_callee_ltopriv@tpoff, %rdx movq %rdx, %rcx movl $main, %edx movl $108032747, %esi movq %rax, %rdi call __gcov_indirect_call_profiler movq $0, %fs:__gcov_indirect_call_callee_ltopriv@tpoff movl $__gcov8.main, %edi call __gcov_time_profiler movl $0, %edx movq __gcov0.main(%rip), %rax addq $1, %rax movq %rax, __gcov0.main(%rip) movl %edx, %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .hidden __gcov_indirect_call_callee_ltopriv .tls_common __gcov_indirect_call_callee_ltopriv,8,8 .hidden __gcov_indirect_call_counters_ltopriv .tls_common __gcov_indirect_call_counters_ltopriv,8,8 .local __gcov0.main .comm __gcov0.main,8,8 .local __gcov8.main .comm __gcov8.main,8,8 .type _GLOBAL__sub_I_65535_0_main, @function ... Honza > > Why would there be a TPOFF32 relocation in the simple test case from > Markus? > > If that is not the assertion, let me know what is. > > Ian [-- Attachment #2: a.o --] [-- Type: application/x-object, Size: 3064 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 1:58 ` Jan Hubicka @ 2014-09-25 15:24 ` Ian Lance Taylor 2014-09-25 15:37 ` H.J. Lu 2014-09-25 16:05 ` Jan Hubicka 0 siblings, 2 replies; 20+ messages in thread From: Ian Lance Taylor @ 2014-09-25 15:24 UTC (permalink / raw) To: Jan Hubicka; +Cc: Markus Trippelsdorf, Ian Lance Taylor, gcc-patches On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: > > b: 00 00 > 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv Look at the .o file where __gcov_indirect_call_counters_ltopriv is defined. That .o file must have the symbol marked as STT_TLS and it must be defined in a section with the SHF_TLS flag. If that is not true, then that is your problem. Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 15:24 ` Ian Lance Taylor @ 2014-09-25 15:37 ` H.J. Lu 2014-09-25 16:24 ` Ian Lance Taylor 2014-09-25 16:05 ` Jan Hubicka 1 sibling, 1 reply; 20+ messages in thread From: H.J. Lu @ 2014-09-25 15:37 UTC (permalink / raw) To: Ian Lance Taylor Cc: Jan Hubicka, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor <iant@google.com> wrote: > On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: >> >> b: 00 00 >> 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv > > Look at the .o file where __gcov_indirect_call_counters_ltopriv is > defined. That .o file must have the symbol marked as STT_TLS and it > must be defined in a section with the SHF_TLS flag. If that is not > true, then that is your problem. SHF_TLS isn't required. 16: 0000000000000008 8 TLS GLOBAL HIDDEN COM __gcov_indirect_call_counters_ltopriv 17: 0000000000000008 8 TLS GLOBAL HIDDEN COM __gcov_indirect_call_callee_ltopriv are also sufficient. -- H.J. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 15:37 ` H.J. Lu @ 2014-09-25 16:24 ` Ian Lance Taylor 2014-09-25 16:30 ` Jan Hubicka 0 siblings, 1 reply; 20+ messages in thread From: Ian Lance Taylor @ 2014-09-25 16:24 UTC (permalink / raw) To: H.J. Lu; +Cc: Jan Hubicka, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor <iant@google.com> wrote: >> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: >>> >>> b: 00 00 >>> 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv >> >> Look at the .o file where __gcov_indirect_call_counters_ltopriv is >> defined. That .o file must have the symbol marked as STT_TLS and it >> must be defined in a section with the SHF_TLS flag. If that is not >> true, then that is your problem. > > SHF_TLS isn't required. > > 16: 0000000000000008 8 TLS GLOBAL HIDDEN COM > __gcov_indirect_call_counters_ltopriv > 17: 0000000000000008 8 TLS GLOBAL HIDDEN COM > __gcov_indirect_call_callee_ltopriv > > are also sufficient. I can create a .o file with a hidden common symbol, but I can't recreate the problem. When I try, gold creates a TLS section and TLS segment itself. How exactly is gold being invoked? Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 16:24 ` Ian Lance Taylor @ 2014-09-25 16:30 ` Jan Hubicka 2014-09-26 2:09 ` Cary Coutant 0 siblings, 1 reply; 20+ messages in thread From: Jan Hubicka @ 2014-09-25 16:30 UTC (permalink / raw) To: Ian Lance Taylor Cc: H.J. Lu, Jan Hubicka, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches > On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > > On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor <iant@google.com> wrote: > >> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: > >>> > >>> b: 00 00 > >>> 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv > >> > >> Look at the .o file where __gcov_indirect_call_counters_ltopriv is > >> defined. That .o file must have the symbol marked as STT_TLS and it > >> must be defined in a section with the SHF_TLS flag. If that is not > >> true, then that is your problem. > > > > SHF_TLS isn't required. > > > > 16: 0000000000000008 8 TLS GLOBAL HIDDEN COM > > __gcov_indirect_call_counters_ltopriv > > 17: 0000000000000008 8 TLS GLOBAL HIDDEN COM > > __gcov_indirect_call_callee_ltopriv > > > > are also sufficient. > > I can create a .o file with a hidden common symbol, but I can't > recreate the problem. When I try, gold creates a TLS section and TLS > segment itself. > > How exactly is gold being invoked? It seems to happen with LTO compilation only, just build mainline tree and try the original testcase. Honza > > Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 16:30 ` Jan Hubicka @ 2014-09-26 2:09 ` Cary Coutant 2014-09-26 2:17 ` Jan Hubicka 0 siblings, 1 reply; 20+ messages in thread From: Cary Coutant @ 2014-09-26 2:09 UTC (permalink / raw) To: Jan Hubicka Cc: Ian Lance Taylor, H.J. Lu, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches The plugin API doesn't have a way to mark a symbol as TLS, but it doesn't really matter since the linker simply overrides the placeholder from the claimed file with the symbol provided in the replacement. Unfortunately, I excluded common symbols from this logic in gold, so the symbol isn't getting marked as TLS COMMON even when we see the real ELF file. I just need to remind myself why the exclusion is there and figure out how to fix it. I think all the information we need is there, so no changes to the plugin API should be necessary. -cary On Thu, Sep 25, 2014 at 9:29 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu <hjl.tools@gmail.com> wrote: >> > On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor <iant@google.com> wrote: >> >> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: >> >>> >> >>> b: 00 00 >> >>> 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv >> >> >> >> Look at the .o file where __gcov_indirect_call_counters_ltopriv is >> >> defined. That .o file must have the symbol marked as STT_TLS and it >> >> must be defined in a section with the SHF_TLS flag. If that is not >> >> true, then that is your problem. >> > >> > SHF_TLS isn't required. >> > >> > 16: 0000000000000008 8 TLS GLOBAL HIDDEN COM >> > __gcov_indirect_call_counters_ltopriv >> > 17: 0000000000000008 8 TLS GLOBAL HIDDEN COM >> > __gcov_indirect_call_callee_ltopriv >> > >> > are also sufficient. >> >> I can create a .o file with a hidden common symbol, but I can't >> recreate the problem. When I try, gold creates a TLS section and TLS >> segment itself. >> >> How exactly is gold being invoked? > > It seems to happen with LTO compilation only, just build mainline tree > and try the original testcase. > > Honza >> >> Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-26 2:09 ` Cary Coutant @ 2014-09-26 2:17 ` Jan Hubicka 2014-09-26 2:42 ` Cary Coutant 2014-09-26 13:07 ` Alan Modra 0 siblings, 2 replies; 20+ messages in thread From: Jan Hubicka @ 2014-09-26 2:17 UTC (permalink / raw) To: Cary Coutant Cc: Jan Hubicka, Ian Lance Taylor, H.J. Lu, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches > The plugin API doesn't have a way to mark a symbol as TLS, but it > doesn't really matter since the linker simply overrides the > placeholder from the claimed file with the symbol provided in the > replacement. Unfortunately, I excluded common symbols from this logic > in gold, so the symbol isn't getting marked as TLS COMMON even when we > see the real ELF file. I just need to remind myself why the exclusion > is there and figure out how to fix it. I think all the information we > need is there, so no changes to the plugin API should be necessary. Thank you! Now when I have your attention, perhaps we could discuss the original motivation of the change that exposed this bug. I was building libreoffice with profile feedback and I run into a message cannot load any more object with static TLS that took me a while to track as I did not see where static TLS is comming out. Ian pointed out to me that static variables with TLS storage also consume static TLS even if they are in dynamic model. This is why I disabled localization. Is there better way to handle this? Note that the variable __gcov_indirect_call_counters_ltopriv was added to work around https://sourceware.org/bugzilla/show_bug.cgi?id=14342 that seems to be fixed. I would like to drop the hack (that will also make profiling to work with current golds again), but I think I would like to document when the bug went away, becuase it is only bit over a year now. Any idea when it was fixed? Honza > > -cary > > > On Thu, Sep 25, 2014 at 9:29 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > >> On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > >> > On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor <iant@google.com> wrote: > >> >> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: > >> >>> > >> >>> b: 00 00 > >> >>> 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv > >> >> > >> >> Look at the .o file where __gcov_indirect_call_counters_ltopriv is > >> >> defined. That .o file must have the symbol marked as STT_TLS and it > >> >> must be defined in a section with the SHF_TLS flag. If that is not > >> >> true, then that is your problem. > >> > > >> > SHF_TLS isn't required. > >> > > >> > 16: 0000000000000008 8 TLS GLOBAL HIDDEN COM > >> > __gcov_indirect_call_counters_ltopriv > >> > 17: 0000000000000008 8 TLS GLOBAL HIDDEN COM > >> > __gcov_indirect_call_callee_ltopriv > >> > > >> > are also sufficient. > >> > >> I can create a .o file with a hidden common symbol, but I can't > >> recreate the problem. When I try, gold creates a TLS section and TLS > >> segment itself. > >> > >> How exactly is gold being invoked? > > > > It seems to happen with LTO compilation only, just build mainline tree > > and try the original testcase. > > > > Honza > >> > >> Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-26 2:17 ` Jan Hubicka @ 2014-09-26 2:42 ` Cary Coutant 2014-09-26 2:50 ` Jan Hubicka 2014-09-26 13:07 ` Alan Modra 1 sibling, 1 reply; 20+ messages in thread From: Cary Coutant @ 2014-09-26 2:42 UTC (permalink / raw) To: Jan Hubicka Cc: Ian Lance Taylor, H.J. Lu, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches > Thank you! Now when I have your attention, perhaps we could discuss the original > motivation of the change that exposed this bug. > I was building libreoffice with profile feedback and I run into a message > > cannot load any more object with static TLS > > that took me a while to track as I did not see where static TLS is comming out. > Ian pointed out to me that static variables with TLS storage also consume > static TLS even if they are in dynamic model. This is why I disabled > localization. Is there better way to handle this? As I understand it, if you compile with -fpic, you shouldn't see any static TLS. The compiler should only use the Local Exec model for static/hidden variables in non-PIC compiles. > Note that the variable __gcov_indirect_call_counters_ltopriv was added to work around > https://sourceware.org/bugzilla/show_bug.cgi?id=14342 > that seems to be fixed. I would like to drop the hack (that will also make > profiling to work with current golds again), but I think I would like to document > when the bug went away, becuase it is only bit over a year now. > > Any idea when it was fixed? I think it was fixed with this patch: https://sourceware.org/ml/binutils/2013-06/msg00139.html I guess I should close that bug. -cary ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-26 2:42 ` Cary Coutant @ 2014-09-26 2:50 ` Jan Hubicka 2014-09-26 3:03 ` Markus Trippelsdorf 0 siblings, 1 reply; 20+ messages in thread From: Jan Hubicka @ 2014-09-26 2:50 UTC (permalink / raw) To: Cary Coutant Cc: Jan Hubicka, Ian Lance Taylor, H.J. Lu, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches > > Thank you! Now when I have your attention, perhaps we could discuss the original > > motivation of the change that exposed this bug. > > I was building libreoffice with profile feedback and I run into a message > > > > cannot load any more object with static TLS > > > > that took me a while to track as I did not see where static TLS is comming out. > > Ian pointed out to me that static variables with TLS storage also consume > > static TLS even if they are in dynamic model. This is why I disabled > > localization. Is there better way to handle this? > > As I understand it, if you compile with -fpic, you shouldn't see any > static TLS. The compiler should only use the Local Exec model for > static/hidden variables in non-PIC compiles. Yep, what seems to be happening is that I have TLS_MODEL_GLOBAL_DYNAMIC variable and I bring it static (or hidden) and it will not have TLS_MODEL_LOCAL_DYNAMIC. In that case it seems that static TLS slots are occupied. > > > Note that the variable __gcov_indirect_call_counters_ltopriv was added to work around > > https://sourceware.org/bugzilla/show_bug.cgi?id=14342 > > that seems to be fixed. I would like to drop the hack (that will also make > > profiling to work with current golds again), but I think I would like to document > > when the bug went away, becuase it is only bit over a year now. > > > > Any idea when it was fixed? > > I think it was fixed with this patch: > > https://sourceware.org/ml/binutils/2013-06/msg00139.html > > I guess I should close that bug. What is the earlierst binutils release fixing the bug? I will add it into changes.html for 5.0. Honza > > -cary ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-26 2:50 ` Jan Hubicka @ 2014-09-26 3:03 ` Markus Trippelsdorf 0 siblings, 0 replies; 20+ messages in thread From: Markus Trippelsdorf @ 2014-09-26 3:03 UTC (permalink / raw) To: Jan Hubicka Cc: Cary Coutant, Ian Lance Taylor, H.J. Lu, Ian Lance Taylor, gcc-patches On 2014.09.26 at 04:50 +0200, Jan Hubicka wrote: > What is the earlierst binutils release fixing the bug? I will add it into > changes.html for 5.0. binutils-2.24 -- Markus ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-26 2:17 ` Jan Hubicka 2014-09-26 2:42 ` Cary Coutant @ 2014-09-26 13:07 ` Alan Modra 2014-09-26 19:16 ` Jan Hubicka 1 sibling, 1 reply; 20+ messages in thread From: Alan Modra @ 2014-09-26 13:07 UTC (permalink / raw) To: Jan Hubicka Cc: Cary Coutant, Ian Lance Taylor, H.J. Lu, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches On Fri, Sep 26, 2014 at 04:17:14AM +0200, Jan Hubicka wrote: > I was building libreoffice with profile feedback and I run into a message > > cannot load any more object with static TLS > > that took me a while to track as I did not see where static TLS is comming out. > Ian pointed out to me that static variables with TLS storage also consume > static TLS even if they are in dynamic model. This is why I disabled > localization. Is there better way to handle this? Fix a glibc bug? It has been a while since I looked into glibc in any depth regarding TLS (2011-03), but I believe the l_tls_modid test here if (! RTLD_SINGLE_THREAD_P && imap->l_tls_modid > DTV_SURPLUS) _dl_signal_error (0, "dlopen", NULL, N_("\ cannot load any more object with static TLS")); is wrong. The test is saying "if we have loaded a certain number of dynamic objects with TLS segments, refuse to dlopen any more containing TLS if we are multi-threaded". What it should be saying is "if we have loaded a certain number of dynamic objects with TLS segments *after we went multi-threaded*, refuse to open any more". In particular, any dynamic objects with TLS segments loaded at program startup should not be counted. This is because DTV_SURPLUS *extra* slots are allocated above those needed at program startup. At least, that's how I think it works. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-26 13:07 ` Alan Modra @ 2014-09-26 19:16 ` Jan Hubicka 0 siblings, 0 replies; 20+ messages in thread From: Jan Hubicka @ 2014-09-26 19:16 UTC (permalink / raw) To: Jan Hubicka, Cary Coutant, Ian Lance Taylor, H.J. Lu, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches > On Fri, Sep 26, 2014 at 04:17:14AM +0200, Jan Hubicka wrote: > > I was building libreoffice with profile feedback and I run into a message > > > > cannot load any more object with static TLS > > > > that took me a while to track as I did not see where static TLS is comming out. > > Ian pointed out to me that static variables with TLS storage also consume > > static TLS even if they are in dynamic model. This is why I disabled > > localization. Is there better way to handle this? > > Fix a glibc bug? It has been a while since I looked into glibc in > any depth regarding TLS (2011-03), but I believe the l_tls_modid test > here > if (! RTLD_SINGLE_THREAD_P && imap->l_tls_modid > DTV_SURPLUS) > _dl_signal_error (0, "dlopen", NULL, N_("\ > cannot load any more object with static TLS")); > > is wrong. The test is saying "if we have loaded a certain number of > dynamic objects with TLS segments, refuse to dlopen any more > containing TLS if we are multi-threaded". > > What it should be saying is "if we have loaded a certain number of > dynamic objects with TLS segments *after we went multi-threaded*, > refuse to open any more". In particular, any dynamic objects with TLS > segments loaded at program startup should not be counted. This is > because DTV_SURPLUS *extra* slots are allocated above those needed at > program startup. At least, that's how I think it works. Yeah, this also looks like very good idea to do (and would solve several practical issues with this limit that I saw while googling for it). Still if someone dlopens bazzilion of shared libraries built with profile feedback and does so after going multithreaded, it should not hit the limit. So I think we need GCC side solution too. Honza > > -- > Alan Modra > Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 15:24 ` Ian Lance Taylor 2014-09-25 15:37 ` H.J. Lu @ 2014-09-25 16:05 ` Jan Hubicka 1 sibling, 0 replies; 20+ messages in thread From: Jan Hubicka @ 2014-09-25 16:05 UTC (permalink / raw) To: Ian Lance Taylor Cc: Jan Hubicka, Markus Trippelsdorf, Ian Lance Taylor, gcc-patches > On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubicka@ucw.cz> wrote: > > > > b: 00 00 > > 9: R_X86_64_TPOFF32 __gcov_indirect_call_counters_ltopriv > > Look at the .o file where __gcov_indirect_call_counters_ltopriv is > defined. That .o file must have the symbol marked as STT_TLS and it > must be defined in a section with the SHF_TLS flag. If that is not > true, then that is your problem. The variable is common, so all the object files define it same way as the .o file I attached. Note that the .o file links just fine when executed out of LTO machinery. Honza > > Ian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-25 0:48 ` Ian Lance Taylor 2014-09-25 1:58 ` Jan Hubicka @ 2014-09-27 7:56 ` Andrew Haley 2014-09-27 8:53 ` Andrew Haley 1 sibling, 1 reply; 20+ messages in thread From: Andrew Haley @ 2014-09-27 7:56 UTC (permalink / raw) Cc: gcc-patches I may be guilty of missing a crucial point here, but: why do we care about having a small limit of static TLS variables? We surely could allocate, say, a megabyte of static TLS for each thread. We already allocate 64M for the thread-local malloc arena, after all. It doesn't cost anything beyond a little address space. What am I missing? Andrew. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Avoid privatization of TLS variables 2014-09-27 7:56 ` Andrew Haley @ 2014-09-27 8:53 ` Andrew Haley 0 siblings, 0 replies; 20+ messages in thread From: Andrew Haley @ 2014-09-27 8:53 UTC (permalink / raw) Cc: gcc-patches On 27/09/14 08:56, Andrew Haley wrote: > I may be guilty of missing a crucial point here, but: why do we care > about having a small limit of static TLS variables? > > We surely could allocate, say, a megabyte of static TLS for each > thread. We already allocate 64M for the thread-local malloc arena, On 64-bit systems, I mean. > after all. It doesn't cost anything beyond a little address space. > > What am I missing? > > Andrew. > ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-09-27 8:53 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-20 3:16 Avoid privatization of TLS variables Jan Hubicka 2014-09-24 17:53 ` Markus Trippelsdorf 2014-09-24 18:18 ` Jan Hubicka 2014-09-24 19:10 ` Markus Trippelsdorf 2014-09-25 0:48 ` Ian Lance Taylor 2014-09-25 1:58 ` Jan Hubicka 2014-09-25 15:24 ` Ian Lance Taylor 2014-09-25 15:37 ` H.J. Lu 2014-09-25 16:24 ` Ian Lance Taylor 2014-09-25 16:30 ` Jan Hubicka 2014-09-26 2:09 ` Cary Coutant 2014-09-26 2:17 ` Jan Hubicka 2014-09-26 2:42 ` Cary Coutant 2014-09-26 2:50 ` Jan Hubicka 2014-09-26 3:03 ` Markus Trippelsdorf 2014-09-26 13:07 ` Alan Modra 2014-09-26 19:16 ` Jan Hubicka 2014-09-25 16:05 ` Jan Hubicka 2014-09-27 7:56 ` Andrew Haley 2014-09-27 8:53 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).