Avoid privatization of TLS variables

Alan Modra amodra@gmail.com
Fri Sep 26 13:07:00 GMT 2014


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



More information about the Gcc-patches mailing list