https://sourceware.org/bugzilla/show_bug.cgi?id=17739
--- Comment #5 from Alan Modra <amodra at gmail dot com> ---
Note that there is more wrong with sh_elf_check_relocs/sh_elf_gc_sweep_hook
than just the reloc mismatch. For instance, this from check_relocs
case R_SH_GOTPLT32:
#ifdef INCLUDE_SHMEDIA
case R_SH_GOTPLT_LOW16:
case R_SH_GOTPLT_MEDLOW16:
case R_SH_GOTPLT_MEDHI16:
case R_SH_GOTPLT_HI16:
case R_SH_GOTPLT10BY4:
case R_SH_GOTPLT10BY8:
#endif
/* If this is a local symbol, we resolve it directly without
creating a procedure linkage table entry. */
if (h == NULL
|| h->forced_local
|| ! info->shared
|| info->symbolic
|| h->dynindx == -1)
goto force_got;
You just can't do that, and expect --gc-sections to work. The trouble is that
flags like h->forced_local and h->dynindx may change in the process of loading
object files. check_relocs is called as each file is loaded, but gc_sweep
after all files are loaded. So gc_sweep can't undo check_relocs plt/got counts
accurately.
A similar problem is seen here
if (! info->shared
&& r_type == R_SH_TLS_IE_32
&& h != NULL
&& h->root.type != bfd_link_hash_undefined
&& h->root.type != bfd_link_hash_undefweak
&& (h->dynindx == -1
|| h->def_regular))
r_type = R_SH_TLS_LE_32;
Again, h->root.type, h->dynindx and h->def_regular may change as object files
are loaded, affecting whether h->got.refcount or h->plt.refcount is incremented
in check_relocs.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
