This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: telling symbols defined only in the linker script
- From: Nick Clifton <nickc at redhat dot com>
- To: aoliva at redhat dot com
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 03 Mar 2004 11:23:26 +0000
- Subject: Re: telling symbols defined only in the linker script
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