On Wed, Sep 24, 2014 at 11:18 AM, Jan Hubicka <hubi...@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
