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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

52 lines
1.9 KiB
Plaintext
Raw Normal View History

[lld] Add REQUIRES: x86 where needed to tests If building lld without x86 support, tests that require that support should be treated as unsupported, not errors. Tested using: 1. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64;X86' make check-lld => Expected Passes : 1406 Unsupported Tests : 287 2. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64' make check-lld => Expected Passes : 410 Unsupported Tests : 1283 Patch by Joel Jones Differential Revision: https://reviews.llvm.org/D47748 llvm-svn: 334095
2018-06-06 21:56:51 +08:00
# REQUIRES: x86
[test] Replace `yaml2obj >` with `yaml2obj -o` and remove unneeded input redirection
2020-08-21 06:00:25 +08:00
# RUN: yaml2obj %p/Inputs/export.yaml -o %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
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck --check-prefix=EXPORT %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
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
[LLD][COFF] Avoid overwriting inputs in tests Before this patch, these two tests were emitting both a .DLL and .LIB. The output .LIB file name also happens to be an input .LIB file name. This prevented the test from executing a second time when LLD is re-entrant (LLD_IN_TEST=2). This is a support patch for https://reviews.llvm.org/D70378.
2020-09-25 01:12:55 +08:00
# RUN: yaml2obj %p/Inputs/export2.yaml -o %t4.obj
# RUN: rm -f %t4.lib
# RUN: llvm-ar cru %t4.lib %t4.obj
# RUN: lld-link /out:%t5.dll /dll %t.obj %t4.lib /export:mangled2
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump -p %t5.dll | FileCheck --check-prefix=EXPORT2 %s
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
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] Fix LLD COFF tests as a follow-up to r327563 I definitely didn't run the tests before committing :( Most of these tests failed because the LLD map file output changed, moving the functions from the main text section to a new per-function section. ICF also started to fire in a few cases, leading to new layouts. llvm-svn: 327571
2018-03-15 04:41:39 +08:00
# RUN: lld-link -opt:noicf /out:%t.lto.dll /dll %t.lto.obj /export:exportfn1 /export:exportfn2
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
# RUN: llvm-objdump -p %t.lto.dll | FileCheck --check-prefix=EXPORT-LTO %s
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
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
[test] Replace `yaml2obj >` with `yaml2obj -o` and remove unneeded input redirection
2020-08-21 06:00:25 +08:00
# RUN: yaml2obj %p/Inputs/import.yaml -o %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
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-imports %t2.exe | FileCheck -check-prefix=IMPORT %s
COFF: Add /implib option. llvm-svn: 240045
2015-06-19 04:27:09 +08:00
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
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --coff-imports %t2.lto.exe | FileCheck -check-prefix=IMPORT %s
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: 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