[llvm-bugs] [Bug 26807] New: --start-lib/--end-lib sometimes ignored with LTO
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Mar 1 18:17:13 PST 2016
https://llvm.org/bugs/show_bug.cgi?id=26807
Bug ID: 26807
Summary: --start-lib/--end-lib sometimes ignored with LTO
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Linker
Assignee: unassignedbugs at nondot.org
Reporter: eugeni.stepanov at gmail.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
This is similar to PR26674, but the problem happens in a different place and
the proposed fix for PR26674 does not affect this. I'm almost sure the bug is
actually in gold, but I can only reproduce it with the LLVM plugin at this
point, so I'm filing the C++-level test case here.
$ cat 1.h
struct A {
A(void *);
};
$ cat 1.cc
#include <stdio.h>
#include "1.h"
A::A(void *p) { printf("register %p\n", p); }
$ cat 2.cc
#include "1.h"
bool q;
static A a(&q);
int main() {}
$ cat 3.cc
#include "1.h"
bool z;
static A a(&z);
$ ./bin/clang++ 1.cc 2.cc 3.cc -flto -c
$ ./bin/clang++ -flto -fuse-ld=gold 2.o -Wl,--start-lib 3.o -Wl,--end-lib
-Wl,--start-lib 3.o -Wl,--end-lib 1.o
/usr/bin/ld.gold: error: 3.o: multiple definition of 'z'
/usr/bin/ld.gold: 3.o: previous definition here
Basically, gold decided to link 3.o even though it does not resolve any new
symbols.
If the second instance of 3.o is removed from the link line, then the link
succeeds, but the resulting executable incorrectly runs the A::A(&z)
initializer (which proves that 3.o was included in the link).
This is the list of symbols that the plugin returns to gold for 3.o, both with
default visibility:
UNDEF _ZN1AC1EPv
DEF z
--
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/20160302/90bd5603/attachment.html>
More information about the llvm-bugs
mailing list