Avoid privatization of TLS variables

Ian Lance Taylor iant@google.com
Thu Sep 25 00:48:00 GMT 2014


On Wed, Sep 24, 2014 at 11:18 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On 2014.09.20 at 05:16 +0200, Jan Hubicka wrote:
>> > Hi,
>> > libreoffice fails to build with TLS because of "Cannot load any more object
>> > with static TLS". Iant pointed out to me the difference that the initial exec
>> > TLS model is also used by static TLS variables.
>> >
>> > This patch prevents turning TLS variables into static that lets me to finish
>> > libreoffice build.
>>
>> This patch triggers an assert in gold:
>>
>> ~ % echo "int main () {}" | g++ -flto -fprofile-generate -x c++ -
>> ld: internal error in relocate_tls, at/gold/x86_64.cc:3829
>> collect2: error: ld returned 1 exit status
>
> I saw this error, too, just not with such a simple testcase :)
> Ian, I think this is bug in gold. What does the assert mean?

I'm not sure because my line numbers don't match.  If it is this
assert:

    case elfcpp::R_X86_64_TPOFF32:          // Local-exec
      if (tls_segment == NULL)
	{
	  gold_assert(parameters->errors()->error_count() > 0
		      || issue_undefined_symbol_error(gsym));
	  return;
	}
      value -= tls_segment->memsz();
      Relocate_functions<size, false>::rela32(view, value, addend);
      break;

then the problem is that there is a TPOFF32 relocation but none of the
input files has a section with the SHF_TLS flag set.  This should not
be possible--the TPOFF32 relocation implies a TLS variable, but the
absence of any SHF_TLS sections implies that there are no TLS
variables.

Why would there be a TPOFF32 relocation in the simple test case from
Markus?

If that is not the assertion, let me know what is.

Ian



More information about the Gcc-patches mailing list