bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/12942] Plugin not handling correctly resolution of COMDATs.


From: cvs-commit at gcc dot gnu.org
Subject: [Bug ld/12942] Plugin not handling correctly resolution of COMDATs.
Date: Sat, 18 Oct 2014 12:44:11 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=12942

--- Comment #7 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  b53dfeb26ed06e97fff1e8f469e33637ebdf6624 (commit)
      from  a841bdf5d3bfb9c687f938be7388597db2e461de (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=b53dfeb26ed06e97fff1e8f469e33637ebdf6624

commit b53dfeb26ed06e97fff1e8f469e33637ebdf6624
Author: Alan Modra <address@hidden>
Date:   Sat Oct 18 21:46:48 2014 +1030

    PowerPC64 ELFv1 function symbol definition vs LTO and discarded sections

    When functions are emitted in comdat groups, global symbols defined in
    duplicates of the group are treated as if they were undefined.  That
    prevents the symbols in the discarded sections from affecting the
    linker's global symbol hash table or causing duplicate symbol errors.
    Annoyingly, when gcc emits a function to a comdat group, it does not
    put *all* of a function's code and data in the comdat group.
    Typically, constant tables, exception handling info, and debug info
    are emitted to normal sections outside of the group, which is a
    perennial source of linker problems due to the special handling needed
    to deal with the extra-group pieces that ought to be discarded.  In
    the case of powerpc64-gcc, the OPD entry for a function is not put in
    the group.  Since the function symbol is defined on the OPD entry this
    means we need to handle symbols in .opd specially.

    To see how this affects LTO in particular, consider the linker
    testcase PR ld/12942 (1).  This testcase links an LTO object file
    pr12942a.o with a normal (non-LTO) object pr12942b.o.  Both objects
    contain a definition for _Z4testv in a comdat group.  On loading
    pr12942a.o, the linker sees a comdat group (actually linkonce section)
    for _Z4testv and a weak _Z4testv defined in the IR.  On loading
    pr12942b.o, the linker sees the same comdat group, and thus discards
    it.  However, _Z4testv is a weak symbol defined in .opd, not part of
    the group, so this weak symbol overrides the weak IR symbol.  On
    (re)loading the LTO version of pr12942a.o, the linker sees another
    weak _Z4testv, but this one does not override the value we have from
    pr12942b.o.  The result is a linker complaint about "`_Z4testv'
    ... defined in discarded section `.group' of tmpdir/pr12942b.o".

        * elf64-ppc.c (ppc64_elf_add_symbol_hook): If function code
        section for function symbols defined in .opd is discarded, let
        the symbol appear to be undefined.
        (opd_entry_value): Ensure the result section is that for the
        function code section in the same object as the OPD entry.

-----------------------------------------------------------------------

Summary of changes:
 bfd/ChangeLog   |    8 ++++
 bfd/elf64-ppc.c |  105 ++++++++++++++++++++++++++++++++----------------------
 2 files changed, 70 insertions(+), 43 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]