Avoid privatization of TLS variables
Fri Sep 26 02:50: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.
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:
> 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.
More information about the Gcc-patches