This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Avoid privatization of TLS variables
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>, Cary Coutant <ccoutant at google dot com>, Ian Lance Taylor <iant at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Markus Trippelsdorf <markus at trippelsdorf dot de>, Ian Lance Taylor <ian at airs dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 26 Sep 2014 21:16:25 +0200
- Subject: Re: Avoid privatization of TLS variables
- Authentication-results: sourceware.org; auth=none
- References: <20140924181836 dot GE6871 at kam dot mff dot cuni dot cz> <CAKOQZ8xMx8bpXGTXN8pd2RC2T9i31brdQTH13ZWiYdooTVq_aw at mail dot gmail dot com> <20140925015835 dot GC26922 at atrey dot karlin dot mff dot cuni dot cz> <CAKOQZ8zwpGfLE02C55iLnDX6rNYAH89nkGFXay2zSTmPidef4w at mail dot gmail dot com> <CAMe9rOqez8GmTu0ZGfyfORJq=fGY8j9J79Ar=LEied=34cgqxw at mail dot gmail dot com> <CAKOQZ8yMkZeaRnmH4Y+coGOFUeK0p5cSuQvsCPDCTn+DHeqw+w at mail dot gmail dot com> <20140925162957 dot GD9303 at kam dot mff dot cuni dot cz> <CAHACq4rseRTNR=i_dYS_TKKEa_UVCA5a0LW+zDDry30fiHCBkg at mail dot gmail dot com> <20140926021714 dot GA5044 at kam dot mff dot cuni dot cz> <20140926130733 dot GE3836 at bubble dot grove dot modra dot org>
> 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