From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@zembu.com>
To: rth@cygnus.com
Cc: binutils@sourceware.cygnus.com
Subject: Re: .dynsym pain
Date: Mon, 12 Jul 1999 20:37:00 -0000
Message-id: <19990713033625.1347.qmail@daffy.airs.com>
References: <19990712180512.A24797@cygnus.com>
X-SW-Source: 1999-q3/msg00166.html

   Date: Mon, 12 Jul 1999 18:05:12 -0700
   From: Richard Henderson <rth@cygnus.com>

   I've a need to install certain STB_LOCAL symbols in the dynamic symbol
   table.  I can't tell you the reason at the moment, but suffice to say
   that they should act like STB_LOCAL symbols do in the normal symbol table.

I assume you mean by this that dynamic relocations can refer to them.
I gather there is some reason that you can't convert the dynamic
relocations to refer to section symbols instead; presumably there is
extra information attached to the STB_LOCAL dynamic symbols somehow.

   First, symbols that began life as local symbols do not have an
   elf_link_hash_entry struct, so there's no existing place to record the
   dynindx.  Further, they're not in the hash table to been seen in the
   several _bfd_elf_link_adjust_dynindx traversals.

Yeah, I don't see how you can put them in the hash table since they
shouldn't have globally visible names.

   Second, symbols that begain life as global symbols, but which were hidden
   by symbol versioning or whatnot, are supposed to have a dynindx of -1. 
   Which gets in the way of the fact that I need it to have an index, but
   to be pushed out with STB_LOCAL rather than whatever it had had before.

I'm not sure why this matters, but I agree with it.

   So I'm wondering how best to go about this.  My current thought is to 
   add a table or linked list to elf_link_hash_table that keeps track of
   the local symbols we want in the dynamic symbol table.  That, plus a
   _bfd_elf_link_record_local_dynamic_symbol entry point, would add direct
   support for this feature to the generic elf linker, and would avoid the
   creation of yet more bed hooks (or alternately introduce yet more 
   hidden order of evaluation fragility).

What type are you going to be put on the linked list?  A hash table
entry?  I guess you basically need enough information to output the
dynamic symbol.  You'll then need to run through the list specially at
some point; you won't want to call elf_link_output_extsym since you
won't want an external symbol.

   It would also necessitate the cleanup of the addition of the sections
   to the dynamic symbol table, as currently happens scattered across all
   the backends and elflink.h.  Because calls to record_dynamic_symbol
   and record_local_dynamic_symbol would be interleaved, we'd need to make
   a pass at the end of bfd_elf,size_dynamic_sections to renumber the 
   dynindx of sections then local syms then global syms.  So we'd actually
   make fewer passes across the data structures.

Yes, I can't think of any reason why we really need to set the dynamic
symbol index in _bfd_elf_link_record_dynamic_symbol.  We just need to
somehow record that the symbol needs a dynamic symbol entry, which
could be done with a flag.  As you say, we could just set all the
dynamic symbol indices near the end of size_dynamic_sections, and that
would be simpler than the current procedure.

Ian