[PATCH] D48402: [mingw] Fix GCC ABI compatibility for comdat things

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 21 10:55:13 PDT 2018


rnk added a comment.

In https://reviews.llvm.org/D48402#1138925, @mstorsjo wrote:

> Seems sensible to me. I've tested this change with LLD as linker as well, and it worked just fine for building Qt, and for a small test setup similar to the example in the issue report.


Hm, I would expect LLD to do the wrong thing for .pdata and .xdata under this scheme. Consider this example where I've made an inline function that has some .pdata:

  $ cat t.h
  void force_pdata();
  inline int foo(int a, int b) {
    force_pdata();
    return a + b;
  }
  
  $ cat a.cpp
  #include "t.h"
  void force_pdata() {}
  int bar(void);
  int __declspec(dllexport) asdf() { return foo(1, 2) + bar(); }
  
  $ cat b.cpp
  #include "t.h"
  int bar() { return foo(3, 4); }
  
  $ gcc -c a.cpp && gcc -c b.cpp && lld-link a.o b.o -dll -out:t.dll  -noentry
  
  $ dumpbin -disasm -pdata t.dll
  ... Disassembly shows four function prologues at:
  0000000180001000:
  0000000180001002:
  0000000180001030:
  0000000180001050:
  
  Function Table (3)
  
             Begin    End      Info      Function Name
  
    00000000 00001000 00001002 000020C8
    0000000C 00001002 0000102F 000020CC
    00000018 00001030 0000104D 000020D8

It looks like LLD is tossing the otherwise unreferenced .pdata and .xdata for the inline function that starts at RVA 0x001050.

If we want LLD to support linking mingw object files from GCC, we'll need to do some extra work in LLD.


https://reviews.llvm.org/D48402





More information about the llvm-commits mailing list