[Bug ld/22832] 2.30 internal error, aborting at ../../bfd/elflink.c:9710 in elf_link_output_extsym

[ebotcazou at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22832

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Thus, when linking one of these object files, that object file's hash table
> never pulls in the definition of __tls_get_addr, and so when
> _bfd_sparc_elf_check_relocs is called for an R_SPARC_TLS_LDM_CALL, it looks
> up __tls_get_addr, doesn't find it, and so an entry is created, since TRUE
> is passed to bfd_link_hash_lookup for create, but this entry has type
> bfd_link_hash_new, and this never changes.
> 
> So it seems to me there are two issues here:
> 
> 1. LLVM should be emitting an entry for __tls_get_addr in its symbol table
> so it is made visible to the object file.
> 
> 2. ld should gracefully handle this case. If this case is an error, it
> should instead be passing FALSE for create to bfd_link_hash_lookup, and if
> the result is NULL, printing an error; otherwise, if this case should work,
> something needs to implicitly pull in the symbol (and in theory LLVM doesn't
> need to change, though in practice it's best to do so anyway for
> compatibility).

Thanks for debugging this.  The irony is that I put TRUE precisely because I
thought it would deal with such a case...  Given that Gold and ld agree, I
think that the error is indeed on the LLVM side but you're right that ld should
handle this more gracefully (it's not too bad either).

Do you want me to prepare a patch or do you intend to do it?

-- 
You are receiving this mail because:
You are on the CC list for the bug.