telling symbols defined only in the linker script

[Alexandre Oliva]

On Mar  1, 2004, Alexandre Oliva <aoliva@redhat.com> wrote:

> 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.

This patch fixes a problem that I thought at first was the one biting
me: in case one symbol is an alias to another, but we have PIC
relocations referencing both of them, we have to merge them into a
single entry, instead of possibly enabling one of the entries to hide
or overwrite the other.

Since the problem I had was unrelated, I ended up adding some code to
verify that no symbol gets more dynamic relocations or rofixup entries
than originally reserved.  Here's the patch that enabled me to figure
out exactly which symbol it was that was getting more entries than
originally reserved.  It adds some needless overhead, so perhaps it
should be conditionally compiled, but the overhead isn't all that
significant, and it's a nice sanity check, so I propose that we
compile it in unconditionally.

Ok to install?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bfd-frv-merge-pic-relocs.patch
Type: text/x-patch
Size: 14737 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040301/137ce481/attachment.bin>
-------------- next part --------------


-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer