[LLVMbugs] [Bug 19848] New: LTO changes results when alias point to weak symbols

[bugzilla-daemon at llvm.org]

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

            Bug ID: 19848
           Summary: LTO changes results when alias point to weak symbols
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, nicholas at mxc.ca,
                    t.p.northover at gmail.com
    Classification: Unclassified

When building with GCC without LTO, a program composed of the files
------------------
#include<stdio.h>
int a = 42;
extern int b;
int main(void) {
  printf("%d %d\n", a, b);
  return 0;
}
----------------

-------------------
__attribute__((weak)) int a = 23;
extern int b __attribute__((alias("a")));
-------------------

prints "42 23".

The reason that the object linker just sees 'a' and 'b' as two independent
symbols. The symbol 'a' is replaced, but 'b' stays.

When building with clang without LTO, the program crashes because clang tells
the linker that 'b' can be discarded and now 'a' points to garbage.

With LTO (both clang and gcc!), this prints "42 42".

This will be a more serious issue when we add comdats: An alias from outside a
comdat that points to a discarded comdat would be an error, but LTO would make
it work.

Changing lib/Linker to work like a native linker would probably involve:

* Expanding alias to not contain other aliases in their ConstantExpr (assuming
we go with aliases that point to ConstantExpr).
* If anything the alias points to is about to be discarded, error.

Given the above existing differences in behaviour I wonder if we could get away
some claver wording in the spec saying that aliases have an undefined value if
the aliasee changes during link.

-- 
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/20140525/4a4cae9b/attachment.html>