bug-binutils
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]