[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