[llvm-bugs] [Bug 32334] New: LLD's /msvclto fails to export some template functions when bitcode files disagree about dllexport

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32334

            Bug ID: 32334
           Summary: LLD's /msvclto fails to export some template functions
                    when bitcode files disagree about dllexport
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: COFF
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org

Consider:

$ cat a.cpp
template <typename T> struct X { void foo() {} };
template struct X<int>;

$ cat b.cpp
template <typename T> struct X { void foo() {} };
struct __declspec(dllexport) B : X<int> { void bar() { foo(); } };

$ clang -flto -fuse-ld=lld a.cpp b.cpp -shared -o t.dll && dumpbin -exports
t.dll | grep foo
          6    5 0000E000 ?foo@?$X at H@@QEAAXXZ

$ clang -flto -fuse-ld=lld a.cpp b.cpp -shared -o t.dll -Wl,-msvclto && dumpbin
-exports t.dll | grep foo
   Creating library t.lib and object t.exp
# nothing

The resulting DLL does not export X<int>::foo.

---

This raises questions about our choice of representation for dllexport. Here
are the two prototypes from the IR:
define weak_odr void @"\01?foo@?$X at H@@QEAAXXZ"(%struct.X* %this)
define weak_odr dllexport void @"\01?foo@?$X at H@@QEAAXXZ"(%struct.X* %this)

Note the dllexport mismatch. The linkage says these things are ODR, but their
dll storage class doesn't match. Is that a problem?

In COFF, exports are identified by a list of /export flags in the .drective
section, so when a comdat section is discarded, we don't lose the information
that the symbol might be exported. It would be possible to generate LLVM IR
like this, where we never use the dllexport storage class and only use the
"Linker Options" module flag to store /export flags. This might solve the
possible ODR violation described above, and would fix this bug.

Personally, I'm not in favor of the change above, but it's worth discussing as
a possible redesign.

-- 
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/20170318/863d3a40/attachment.html>