This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Futility in _bfd_elf_link_hash_hide_symbol


While debugging ld this week, I noticed something interesting.  We call
_bfd_elf_link_hash_hide_symbol (via elf_backend_hide_symbol) from
elf_link_add_object_symbols in some cases.  That means during
processing of each input object, so the backend check_relocs may be
called both before and after.

_bfd_elf_link_hash_hide_symbol sets the forced_local flag if asked to
(which it always is when called early).  But it also does these:

  h->plt = elf_hash_table (info)->init_offset;
  h->needs_plt = 0;

The backend check_relocs will then go right ahead incrementing
h->plt.refcount (including from -1 to 0) and setting h->needs_plt.
So in fact these don't necessarily accomplish anything.

I think I've convinced myself that it's harmless, but it's twisty.
If there were any way to call hide_symbol while reading object files
that wouldn't also cause it to get called again in
_bfd_elf_fix_symbol_flags, then the h->plt.refcount > 0 tests scattered
through various backends wouldn't work, and we'd get extra PLT entries.

If anyone has a good idea to clean this up so that we don't
re-increment the refcount, I'm listening.  I suppose one way would be
to make backends check whether the refcount was -1 before touching it.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]