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/export32.test

134 lines
4.6 KiB
Plaintext
Raw Normal View History

COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# RUN: yaml2obj < %s > %t.obj
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +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 /export:exportfn1 /export:exportfn2
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK1 %s
Handle writeImportLibrary failing. We were printing an error but exiting with 0. Not sure how to test this. We could add a no-winlib feature, but that is probably not worth it. llvm-svn: 244109
2015-08-06 04:03:57 +08:00
# REQUIRES: winlib
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# CHECK1: Export Table:
# CHECK1: DLL name: export32.test.tmp.dll
# CHECK1: Ordinal RVA Name
# CHECK1-NEXT: 0 0
# CHECK1-NEXT: 1 0x1008 exportfn1
# CHECK1-NEXT: 2 0x1010 exportfn2
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +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 /export:exportfn1,@5 \
COFF: Find C++ mangled name for symbols starting with underscore. Symbol foo is mangled as _foo in C and ?foo@@... in C++ on x86. findMangle has to remove prefix underscore before mangle a given name as a C++ symbol. llvm-svn: 241874
2015-07-10 07:03:51 +08:00
# RUN: /export:exportfn2 /export:mangled
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK2 %s
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# CHECK2: Export Table:
# CHECK2: DLL name: export32.test.tmp.dll
# CHECK2: Ordinal RVA Name
# CHECK2-NEXT: 0 0
# CHECK2-NEXT: 1 0
# CHECK2-NEXT: 2 0
# CHECK2-NEXT: 3 0
# CHECK2-NEXT: 4 0
# CHECK2-NEXT: 5 0x1008 exportfn1
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
# CHECK2-NEXT: 6 0x1010 exportfn2
# CHECK2-NEXT: 7 0x1010 exportfn3
# CHECK2-NEXT: 8 0x1010 mangled
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +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 /export:exportfn1,@5,noname /export:exportfn2
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK3 %s
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# CHECK3: Export Table:
# CHECK3: DLL name: export32.test.tmp.dll
# CHECK3: Ordinal RVA Name
# CHECK3-NEXT: 0 0
# CHECK3-NEXT: 1 0
# CHECK3-NEXT: 2 0
# CHECK3-NEXT: 3 0
# CHECK3-NEXT: 4 0
# CHECK3-NEXT: 5 0x1008
# CHECK3-NEXT: 6 0x1010 exportfn2
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +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 /export:f1=exportfn1 /export:f2=exportfn2
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK4 %s
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# CHECK4: Export Table:
# CHECK4: DLL name: export32.test.tmp.dll
# CHECK4: Ordinal RVA Name
# CHECK4-NEXT: 0 0
# CHECK4-NEXT: 1 0x1010 exportfn3
# CHECK4-NEXT: 2 0x1008 f1
# CHECK4-NEXT: 3 0x1010 f2
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: echo "EXPORTS exportfn1 @3" > %t.def
# RUN: echo "fn2=exportfn2 @2" >> %t.def
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 /def:%t.def
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK5 %s
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# CHECK5: Export Table:
# CHECK5: DLL name: export32.test.tmp.dll
# CHECK5: Ordinal RVA Name
# CHECK5-NEXT: 0 0
# CHECK5-NEXT: 1 0
# CHECK5-NEXT: 2 0x1010 fn2
# CHECK5-NEXT: 3 0x1008 exportfn1
# CHECK5-NEXT: 4 0x1010 exportfn3
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +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 /export:exportfn1 /export:exportfn2 \
COFF: Fix dllexported symbol names on x86. Symbol names are usually mangled by appending "_" prefix on x86. But the mangled name is not used in DLL export table. The export table contains unmangled names. llvm-svn: 241872
2015-07-10 06:51:41 +08:00
# RUN: /export:exportfn1 /export:exportfn2,@5 >& %t.log
# RUN: FileCheck -check-prefix=CHECK6 %s < %t.log
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
# CHECK6: duplicate /export option: _exportfn2
# CHECK6-NOT: duplicate /export option: _exportfn1
---
header:
Machine: IMAGE_FILE_MACHINE_I386
Characteristics: []
sections:
- Name: .text
Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
Alignment: 4
SectionData: B800000000506800000000680000000050E80000000050E800000000
- Name: .drectve
Characteristics: [ IMAGE_SCN_LNK_INFO, IMAGE_SCN_LNK_REMOVE ]
[COFF] Correct tests with bogus alignment llvm-svn: 263838
2016-03-19 05:47:12 +08:00
Alignment: 1
COFF: Fix export symbol names for x86. I don't fully understand the rationale behind the name mangling scheme used for the DLL export table and the import library. Why only leading "_" is dropped for the import library while both "_" and "@" are dropped from DLL symbol table? But this seems to be what MSVC linker does. llvm-svn: 243490
2015-07-29 06:34:24 +08:00
SectionData: 2f6578706f72743a5f6578706f7274666e3300 # /export:_exportfn3
symbols:
- Name: .text
Value: 0
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_STATIC
SectionDefinition:
Length: 28
NumberOfRelocations: 4
NumberOfLinenumbers: 0
CheckSum: 0
Number: 0
- Name: __DllMainCRTStartup@12
Value: 0
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
- Name: _exportfn1
Value: 8
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
- Name: _exportfn2@4
Value: 16
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
- Name: _exportfn3
Value: 16
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
- Name: '?mangled@@YAHXZ'
Value: 16
SectionNumber: 1
SimpleType: IMAGE_SYM_TYPE_NULL
ComplexType: IMAGE_SYM_DTYPE_NULL
StorageClass: IMAGE_SYM_CLASS_EXTERNAL
...