Avoid privatization of TLS variables

Cary Coutant ccoutant@google.com
Fri Sep 26 02:42:00 GMT 2014


> 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



More information about the Gcc-patches mailing list