https://sourceware.org/bugzilla/show_bug.cgi?id=13557
--- Comment #17 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot
gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 02eb0a49bceb35e4b0503e6ffc11e85151dbc571 (commit)
via 13e570f80cbfb299a8858ce6830e91a6cb40ab7b (commit)
from 241fd515ad94fa11d4608d4fe8108c382792d3be (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=02eb0a49bceb35e4b0503e6ffc11e85151dbc571
commit 02eb0a49bceb35e4b0503e6ffc11e85151dbc571
Author: Alan Modra <amo...@gmail.com>
Date: Tue Aug 5 10:48:47 2014 +0930
Fix load of archive element with common def for -u sym
* linker.c (generic_link_check_archive_element): Move handling
of command link -u symbols with a common symbol def to the
code handling non-common symbols so that archive element symbols
are loaded. Use generic_link_add_object_symbols.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=13e570f80cbfb299a8858ce6830e91a6cb40ab7b
commit 13e570f80cbfb299a8858ce6830e91a6cb40ab7b
Author: Alan Modra <amo...@gmail.com>
Date: Tue Aug 5 10:46:57 2014 +0930
Fix LTO vs. COFF archives
Avoid scan of symbols on objects in coff archives since we don't need
to do anything special with common symbols. The scan is quite useless,
and breaks LTO due to slim LTO objects not having symbols available
until after the plugin has claimed them. Instead we can add objects
based on their archive symbol map.
Also, rip out the archive symbol hash table used by the generic
linker. Using a hash breaks one feature of unix archive linking;
The first object file in an archive defining any given symbol should
be the object extracted to satisfy that symbol. What's more a hash
isn't much faster except in pathological cases where object file
ordering causes many scans of the archive. See the comment which I'm
removing from elf_link_add_archive_symbols.
Finally, tidy elflink.c archive handling a little.
PR 13557
* linker.c (struct archive_list, struct archive_hash_entry,
struct archive_hash_table, archive_hash_newfunc,
archive_hash_table_init, archive_hash_lookup, archive_hash_allocate,
archive_hash_table_free): Delete.
(_bfd_generic_link_add_archive_symbols): Add h and name params to
checkfn. Rewrite using a straight-forward scan over archive map.
(generic_link_check_archive_element_no_collect,
generic_link_check_archive_element_collect,
generic_link_check_archive_element): Add h and name params.
* aoutx.h (aout_link_check_archive_element): Likewise.
* pdp11.c (aout_link_check_archive_element): Likewise.
* xcofflink.c (xcoff_link_check_archive_element): Likewise.
* cofflink.c (coff_link_check_archive_element): Likewise. Don't
scan symbols, simply add archive element whenever h is undefined.
(coff_link_check_ar_symbols): Delete.
* ecoff.c (read_ext_syms_and_strs): Delete.
(reread_ext_syms_and_strs): Delete.
(ecoff_link_check_archive_element): Add h and name param. Don't
scan symbols, simply add based on h. Use
ecoff_link_add_object_symbols.
* elflink.c (elf_link_is_defined_archive_symbol): Don't test
archive_pass.
(elf_link_add_archive_symbols): Delete "defined" array, merge
functionality into "included". Make "included" a char array. Don't
set or test archive_pass.
* libbfd-in.h (_bfd_generic_link_add_archive_symbols): Update.
* libbfd.h: Regenerate.
-----------------------------------------------------------------------
Summary of changes:
bfd/ChangeLog | 37 +++++
bfd/aoutx.h | 2 +
bfd/cofflink.c | 116 ++--------------
bfd/ecoff.c | 164 ++---------------------
bfd/elflink.c | 53 ++------
bfd/libbfd-in.h | 4 +-
bfd/libbfd.h | 4 +-
bfd/linker.c | 410 ++++++++++++++++---------------------------------------
bfd/pdp11.c | 4 +-
bfd/xcofflink.c | 4 +-
10 files changed, 204 insertions(+), 594 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
