[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binuti
From: |
ccoutant at gmail dot com |
Subject: |
[Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418 |
Date: |
Tue, 12 Jan 2016 07:19:01 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=19353
Cary Coutant <ccoutant at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|ccoutant at gmail dot com |shenhan at google dot
com
--- Comment #5 from Cary Coutant <ccoutant at gmail dot com> ---
(In reply to Han Shen from comment #4)
> Hi, Kristof, I was able to reproduce case 2 (but not 1).
>
> In gold, tls_segment is never created in layout.cc, so comes the assertion.
> In call_once.o, there is the tls symbol _ZSt15__once_callable, however there
> is no sections that has bit elfcpp::SHF_TLS turned on, and tls_segment is
> only created if there is at least one sectoin with SHF_TLS bit.
>
> So, Cary, shall we create the tls_segment whenever the Scanner encounters a
> tls symbol?
It looks like this is in relocate_tls(), in this block:
case elfcpp::R_AARCH64_TLSDESC_ADR_PAGE21:
case elfcpp::R_AARCH64_TLSDESC_LD64_LO12:
case elfcpp::R_AARCH64_TLSDESC_ADD_LO12:
case elfcpp::R_AARCH64_TLSDESC_CALL:
...
if (tlsopt == tls::TLSOPT_TO_IE)
{
if (tls_segment == NULL)
{
gold_assert(parameters->errors()->error_count() > 0
|| issue_undefined_symbol_error(gsym));
return aarch64_reloc_funcs::STATUS_BAD_RELOC;
}
return tls_desc_gd_to_ie(relinfo, target, rela, r_type,
view, psymval, got_entry_address,
address);
}
at the gold_assert() there. Is that where the assert is happening for you?
Looking at tls_desc_gd_to_ie(), and comparing this with the similar case in the
x86 backend, it looks to me like the insistence on having a non-NULL
tls_segment here is too zealous -- the optimization from GD to IE never needs
tls_segment, and it's perfectly reasonable to have a relocation to an external
TLS symbol without having a TLS segment in the main executable.
I think if you simply remove the "if (tls_segment == NULL) { ... }" block here,
it will fix the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418, kristof.beyls at gmail dot com, 2016/01/05
- [Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418, shenhan at google dot com, 2016/01/07
- [Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418,
ccoutant at gmail dot com <=
- [Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418, ccoutant at gmail dot com, 2016/01/12
- [Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418, cvs-commit at gcc dot gnu.org, 2016/01/12
- [Bug gold/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418, ccoutant at gmail dot com, 2016/01/12