telling symbols defined only in the linker script

[Nick Clifton]

Hi Alex,

> I've run into a problem in FR-V FDPIC, while linking static
> executables, if a symbol is weak-referenced but not defined except
> for an assignment in a linker script.  We fail to allocate a rofixup
> entry for it, because at size_dynamic_sections() time it's still
> undefweak, but when we get to the point of emitting rofixups, it's
> become defined, so we emit a rofixup and end up missing entries at
> the end.
> 
> OTOH, I can't tentatively allocate rofixup entries for undefweak
> symbols, because there must not be unused rofixup entries.
> 
> So, I need to arrange for symbols that are defined in the linker
> script to not show up as undefweak.  I've come up with the following
> patch, but I'm not entirely happy with it.  It require code in
> size_dynamic_sections, for example, to know that bfd_type_hash_new
> means a symbol that used to be undefweak or undefined but that was
> defined in the linker script.  Changing the type of the symbol to
> defined (which feels like the right thing to do) would cause
> PROVIDEs to no longer work, so that's not an option.  I considered
> introducing bfd_type_hash_assigned, but I'm concerned that existing
> code might fail to handle it properly.
> 
> Opinions?  Does this look ok to install?

Well, I think that your approach is the best one without actually
defining a new hash type.  That would probably require lots more
changes to generic code, and take a while for the bugs to be ironed
out, so I think that we should go with your approach for now.


> Index: bfd/ChangeLog
> from  Alexandre Oliva  <aoliva@redhat.com>
> 
> 	* elflink.c (bfd_elf_record_link_assignment): Mark undefweak and
> 	undefined symbols as hash_new.

Approved for mainline.  Not sure about the branch though, since I am
concerned that this patch might introduce a subtle new bug that will
take some time to detect.  ie there might be some code that depends
upon the undefweak/undefined type continuing to exist.  I cannot think
of any at the moment, but there might be.  Which is why I would prefer
to have more time to test the patch in the wild before it becomes part
of an official release.  It is Daniel's call though...

Cheers
        Nick