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 <hubi...@ucw.cz> wrote: >> On Thu, Sep 25, 2014 at 8:37 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> > On Thu, Sep 25, 2014 at 8:24 AM, Ian Lance Taylor <i...@google.com> wrote: >> >> On Wed, Sep 24, 2014 at 6:58 PM, Jan Hubicka <hubi...@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
