The fix for PR ld/22727 on SPARC passed TRUE as the 'create' argument
in the call to bfd_link_hash_lookup. It turns out this was a bad idea
because, if the symbol is created at this point, the link will abort
later in elf_link_output_extsym. This changes the TRUE into a FALSE
and puts an assertion on the result of the call, making it easier to
debug the issue; that's exactly in keeping with what Gold does.
bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) <R_SPARC_TLS_GD_CALL>:
Pass FALSE instead of TRUE as 'create' argument to bfd_link_hash_lookup
and assert that the result of the call is not NULL.
+2018-02-15 Eric Botcazou <ebotcazou@adacore.com>
+
+ PR ld/22832
+ * elfxx-sparc.c (_bfd_sparc_elf_check_relocs) <R_SPARC_TLS_GD_CALL>:
+ Pass FALSE instead of TRUE as 'create' argument to bfd_link_hash_lookup
+ and assert that the result of the call is not NULL.
+
2018-02-14 Nick Clifton <nickc@redhat.com>
PR 22823
/* Essentially R_SPARC_WPLT30 relocs against __tls_get_addr. */
h = (struct elf_link_hash_entry *)
- bfd_link_hash_lookup (info->hash, "__tls_get_addr", TRUE,
+ bfd_link_hash_lookup (info->hash, "__tls_get_addr", FALSE,
FALSE, TRUE);
+ BFD_ASSERT (h != NULL);
/* Fall through */
case R_SPARC_WPLT30: