[LLVMbugs] [Bug 15919] New: LLVM can emit hidden undefined weak symbols which trip up Gold

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15919

            Bug ID: 15919
           Summary: LLVM can emit hidden undefined weak symbols which trip
                    up Gold
           Product: new-bugs
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: cs448 at cam.ac.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When performing a link with gold and the LLVMgold plugin LLVM can emit
hidden-weak-undefined symbols which break the linker.

If linking with a file containing 

declare extern_weak hidden void @_stdio_init() (example from uclibc)

the LLVM plugin disguises the fact that the extern is annotated hidden
and just describes it was weak-undef to Gold. However its subterfuge cannot
last, and it is discovered after LLVM lowers the LTO'd IR to a plain ELF binary
and Gold rereads, I guess to check if LLVM introduced calls (e.g. to memcpy).
At that stage it notices the extern is still declared hidden-weak-undef and
merges the symbol table entries.

This could be argued as a bug in Gold (and I've submitted the report to
binutils bugzilla too, http://sourceware.org/bugzilla/show_bug.cgi?id=15435);
the question is does the flag combination weak-hidden-undefined mean anything?
In my opinion it does:

Weak-extern means that the symbol is null unless defined, but AFAIK admits some
degree of binding at dynamic-link time.

Hidden-extern means the symbol must be defined within the current shared
object.

Weak-hidden-extern would mean that the symbol is null unless defined, and no
definition is admissible at all if not in this shared object -- on final link
for this so the linker can throw the symbol away.

Regardless it's (a) possible the Binutils people will disagree and say it's a
bad combination, in which case LLVM should squash hidden and write it out as
weak-undef-default,  and (b) whether it's sensible or not it's tripping the
linker up and causing "hidden symbol not defined in this object" errors, so at
least for now this suggests to me LLVM should not write ELF objects with that
attribute combination.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130506/35751356/attachment.html>