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: Ian Lance Taylor <iant at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: 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: Wed, 24 Sep 2014 17:48:36 -0700
- Subject: Re: Avoid privatization of TLS variables
- Authentication-results: sourceware.org; auth=none
- References: <20140920031617 dot GB2325 at kam dot mff dot cuni dot cz> <20140924175326 dot GE29454 at x4> <20140924181836 dot GE6871 at kam dot mff dot cuni dot cz>
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