maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/COFF/dll.test

51 lines
1.9 KiB
Plaintext
Raw Normal View History

COFF: Create import library files. On Windows, we have to create a .lib file for each .dll. When linking against DLLs, the linker doesn't use the DLL files, but instead read a list of dllexported symbols from corresponding lib files. A library file containing descriptors of a DLL is called an import library file. lib.exe has a feature to create an import library file from a module-definition file. In this patch, we create a module-definition file and pass that to lib.exe. We eventually want to create an import library file by ourselves to eliminate dependency to lib.exe. For now, we just use the MSVC tool. llvm-svn: 239937
2015-06-18 04:40:43 +08:00
# RUN: yaml2obj < %p/Inputs/export.yaml > %t.obj
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t.dll /dll %t.obj /export:exportfn1 /export:exportfn2 \
COFF: Allow mangled symbols as arguments for /export. Usually dllexported symbols are defined with 'extern "C"', so identifying them is easy. We can just do hash table lookup to look up exported symbols. However, C++ non-member functions are also allowed to be exported, and they can be specified with unmangled name. So, if /export:foo is given, we need to look up not only "foo" but also its all mangled names. In MSVC mangling scheme, that means that we need to look up any symbol which starts with "?foo@@Y". In this patch, we scan the entire symbol table to search for a mangled symbol. The symbol table is a DenseMap, and that doesn't support table lookup by string prefix. This is of course very inefficient. But that should be probably OK because the user should always add 'extern "C"' to dllexported symbols. llvm-svn: 240919
2015-06-29 06:16:41 +08:00
# RUN: /export:mangled
COFF: Create import library files. On Windows, we have to create a .lib file for each .dll. When linking against DLLs, the linker doesn't use the DLL files, but instead read a list of dllexported symbols from corresponding lib files. A library file containing descriptors of a DLL is called an import library file. lib.exe has a feature to create an import library file from a module-definition file. In this patch, we create a module-definition file and pass that to lib.exe. We eventually want to create an import library file by ourselves to eliminate dependency to lib.exe. For now, we just use the MSVC tool. llvm-svn: 239937
2015-06-18 04:40:43 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=EXPORT %s
EXPORT: Export Table:
EXPORT: DLL name: dll.test.tmp.dll
EXPORT: Ordinal RVA Name
EXPORT-NEXT: 0 0
COFF: Improve dllexported name mangling compatibility. The rules for dllexported symbols are overly complicated due to x86 name decoration, fuzzy symbol resolution, and the fact that one symbol can be resolved by so many different names. The rules are probably intended to be "intuitive", so that users don't have to understand the name mangling schemes, but it seems that it can lead to unintended symbol exports. To make it clear what I'm trying to do with this patch, let me write how the export rules are subtle and complicated. - x86 name decoration: If machine type is i386 and export name is given by a command line option, like /export:foo, the real symbol name the linker has to search for is _foo because all symbols are decorated with "_" prefixes. This doesn't happen on non-x86 machines. This automatic name decoration happens only when the name is not C++ mangled. However, the symbol name exported from DLLs are ones without "_" on all platforms. Moreover, if the option is given via .drectve section, no symbol decoration is done (the reason being that the .drectve section is created by a compiler and the compiler should always know the exact name of the symbol, I guess). - Fuzzy symbol resolution: In addition to x86 name decoration, the linker has to look for cdecl or C++ mangled symbols for a given /export. For example, it searches for not only _foo but also _foo@<number> or ??foo@... for /export:foo. Previous implementation didn't get it right. I'm trying to make it as compatible with MSVC linker as possible with this patch however the rules are. The new code looks a bit messy to me, but I don't think it can be simpler due to the ad-hoc-ness of the rules. llvm-svn: 246424
2015-08-31 16:43:21 +08:00
EXPORT-NEXT: 1 0x1008 exportfn1
EXPORT-NEXT: 2 0x1010 exportfn2
EXPORT-NEXT: 3 0x1010 exportfn3
EXPORT-NEXT: 4 0x1010 mangled
COFF: Implement DLL symbol exports for bitcode files. Differential Revision: http://reviews.llvm.org/D10530 llvm-svn: 239994
2015-06-18 13:22:15 +08:00
COFF: Fix /export. Mangled dllexported symbols may be defined in a library. If that's the case, we have to read a member file from the library. llvm-svn: 240947
2015-06-29 22:27:10 +08:00
# RUN: yaml2obj < %p/Inputs/export2.yaml > %t5.obj
# RUN: rm -f %t5.lib
# RUN: llvm-ar cru %t5.lib %t5.obj
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t5.dll /dll %t.obj %t5.lib /export:mangled2
COFF: Fix /export. Mangled dllexported symbols may be defined in a library. If that's the case, we have to read a member file from the library. llvm-svn: 240947
2015-06-29 22:27:10 +08:00
# RUN: llvm-objdump -p %t5.dll | FileCheck -check-prefix=EXPORT2 %s
EXPORT2: Export Table:
EXPORT2: DLL name: dll.test.tmp5.dll
EXPORT2: Ordinal RVA Name
EXPORT2-NEXT: 0 0
COFF: Improve dllexported name mangling compatibility. The rules for dllexported symbols are overly complicated due to x86 name decoration, fuzzy symbol resolution, and the fact that one symbol can be resolved by so many different names. The rules are probably intended to be "intuitive", so that users don't have to understand the name mangling schemes, but it seems that it can lead to unintended symbol exports. To make it clear what I'm trying to do with this patch, let me write how the export rules are subtle and complicated. - x86 name decoration: If machine type is i386 and export name is given by a command line option, like /export:foo, the real symbol name the linker has to search for is _foo because all symbols are decorated with "_" prefixes. This doesn't happen on non-x86 machines. This automatic name decoration happens only when the name is not C++ mangled. However, the symbol name exported from DLLs are ones without "_" on all platforms. Moreover, if the option is given via .drectve section, no symbol decoration is done (the reason being that the .drectve section is created by a compiler and the compiler should always know the exact name of the symbol, I guess). - Fuzzy symbol resolution: In addition to x86 name decoration, the linker has to look for cdecl or C++ mangled symbols for a given /export. For example, it searches for not only _foo but also _foo@<number> or ??foo@... for /export:foo. Previous implementation didn't get it right. I'm trying to make it as compatible with MSVC linker as possible with this patch however the rules are. The new code looks a bit messy to me, but I don't think it can be simpler due to the ad-hoc-ness of the rules. llvm-svn: 246424
2015-08-31 16:43:21 +08:00
EXPORT2-NEXT: 1 0x1010 exportfn3
EXPORT2-NEXT: 2 0x101c mangled2
COFF: Fix /export. Mangled dllexported symbols may be defined in a library. If that's the case, we have to read a member file from the library. llvm-svn: 240947
2015-06-29 22:27:10 +08:00
COFF: Implement DLL symbol exports for bitcode files. Differential Revision: http://reviews.llvm.org/D10530 llvm-svn: 239994
2015-06-18 13:22:15 +08:00
# RUN: llvm-as -o %t.lto.obj %p/Inputs/export.ll
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t.lto.dll /dll %t.lto.obj /export:exportfn1 /export:exportfn2
COFF: Implement DLL symbol exports for bitcode files. Differential Revision: http://reviews.llvm.org/D10530 llvm-svn: 239994
2015-06-18 13:22:15 +08:00
# RUN: llvm-objdump -p %t.lto.dll | FileCheck -check-prefix=EXPORT-LTO %s
EXPORT-LTO: Export Table:
EXPORT-LTO: DLL name: dll.test.tmp.lto.dll
EXPORT-LTO: Ordinal RVA Name
EXPORT-LTO-NEXT: 0 0
EXPORT-LTO-NEXT: 1 0x1010 exportfn1
EXPORT-LTO-NEXT: 2 0x1020 exportfn2
EXPORT-LTO-NEXT: 3 0x1030 exportfn3
COFF: Create import library files. On Windows, we have to create a .lib file for each .dll. When linking against DLLs, the linker doesn't use the DLL files, but instead read a list of dllexported symbols from corresponding lib files. A library file containing descriptors of a DLL is called an import library file. lib.exe has a feature to create an import library file from a module-definition file. In this patch, we create a module-definition file and pass that to lib.exe. We eventually want to create an import library file by ourselves to eliminate dependency to lib.exe. For now, we just use the MSVC tool. llvm-svn: 239937
2015-06-18 04:40:43 +08:00
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t.dll /dll %t.obj /implib:%t2.lib \
COFF: Allow mangled symbols as arguments for /export. Usually dllexported symbols are defined with 'extern "C"', so identifying them is easy. We can just do hash table lookup to look up exported symbols. However, C++ non-member functions are also allowed to be exported, and they can be specified with unmangled name. So, if /export:foo is given, we need to look up not only "foo" but also its all mangled names. In MSVC mangling scheme, that means that we need to look up any symbol which starts with "?foo@@Y". In this patch, we scan the entire symbol table to search for a mangled symbol. The symbol table is a DenseMap, and that doesn't support table lookup by string prefix. This is of course very inefficient. But that should be probably OK because the user should always add 'extern "C"' to dllexported symbols. llvm-svn: 240919
2015-06-29 06:16:41 +08:00
# RUN: /export:exportfn1 /export:exportfn2
Fix test/COFF/dll.test after r242342. r242342 removed the RUN line that wrote t2.obj, but another RUN line further down still reads t2.obj, so add it back. llvm-svn: 242415
2015-07-17 00:45:01 +08:00
# RUN: yaml2obj < %p/Inputs/import.yaml > %t2.obj
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t2.exe /entry:main %t2.obj %t2.lib
COFF: Add /implib option. llvm-svn: 240045
2015-06-19 04:27:09 +08:00
# RUN: llvm-readobj -coff-imports %t2.exe | FileCheck -check-prefix=IMPORT %s
COFF: Make test commands shorter. NFC. llvm-svn: 244227
2015-08-07 00:47:46 +08:00
# RUN: lld-link /out:%t2.lto.exe /entry:main %t2.obj %t.lto.lib
COFF: Implement DLL symbol exports for bitcode files. Differential Revision: http://reviews.llvm.org/D10530 llvm-svn: 239994
2015-06-18 13:22:15 +08:00
# RUN: llvm-readobj -coff-imports %t2.lto.exe | FileCheck -check-prefix=IMPORT %s
COFF: Create import library files. On Windows, we have to create a .lib file for each .dll. When linking against DLLs, the linker doesn't use the DLL files, but instead read a list of dllexported symbols from corresponding lib files. A library file containing descriptors of a DLL is called an import library file. lib.exe has a feature to create an import library file from a module-definition file. In this patch, we create a module-definition file and pass that to lib.exe. We eventually want to create an import library file by ourselves to eliminate dependency to lib.exe. For now, we just use the MSVC tool. llvm-svn: 239937
2015-06-18 04:40:43 +08:00
IMPORT: Symbol: exportfn1
IMPORT: Symbol: exportfn2