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

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

158 lines
5.7 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] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /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
COFF: Process /merge flag as we create output sections. With this we can merge builtin sections. Differential Revision: https://reviews.llvm.org/D45350 llvm-svn: 329471
2018-04-07 08:46:55 +08:00
#
[COFF] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /out:%t.dll /dll %t.obj /export:exportfn1 /export:exportfn2 /merge:.edata=.rdata
COFF: Process /merge flag as we create output sections. With this we can merge builtin sections. Differential Revision: https://reviews.llvm.org/D45350 llvm-svn: 329471
2018-04-07 08:46:55 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK1 %s
[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 --file-headers --sections %t.dll | FileCheck -check-prefix=HEADER-MERGE %s
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: Process /merge flag as we create output sections. With this we can merge builtin sections. Differential Revision: https://reviews.llvm.org/D45350 llvm-svn: 329471
2018-04-07 08:46:55 +08:00
# HEADER-MERGE: ExportTableRVA: 0x2000
# HEADER-MERGE-NEXT: ExportTableSize: 0x7E
# HEADER-MERGE: Name: .rdata
# HEADER-MERGE-NEXT: VirtualSize: 0x7E
# HEADER-MERGE-NEXT: VirtualAddress: 0x2000
[COFF] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /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] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /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] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /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] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /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] Add a test for def files with spaces between @ and ordinal Differential Revision: https://reviews.llvm.org/D39328 llvm-svn: 316691
2017-10-27 04:11:54 +08:00
# RUN: echo "EXPORTS exportfn1 @ 3" > %t.def
# RUN: echo "fn2=exportfn2 @ 2" >> %t.def
[COFF] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /out:%t.dll /dll %t.obj /def:%t.def
[COFF] Add a test for def files with spaces between @ and ordinal Differential Revision: https://reviews.llvm.org/D39328 llvm-svn: 316691
2017-10-27 04:11:54 +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] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /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
[COFF] Implement /safeseh:no and check @feat.00 flags by default Summary: Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and defined __safe_se_handler_table & size. Now, /safeseh:no leaves those undefined. Additionally, we were checking for the safeseh @feat.00 flag in two places: once to emit errors, and once during safeseh table construction. The error was set up to be off by default, but safeseh is supposed to be on by default. I combined the two checks, so now LLD emits an error if an input object lacks @feat.00 and safeseh is enabled. This caused the majority of 32-bit LLD tests to fail, since many test input object files lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to preserve behavior. Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any input file wasn't compiled for safeseh. Reviewers: mstorsjo, ruiu, thakis Reviewed By: ruiu, thakis Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63570 llvm-svn: 366238
2019-07-17 02:17:33 +08:00
# RUN: lld-link -safeseh:no /out:%t.dll /dll %t.obj /export:foo=mangled
Fix wrong assertion failure. Previously, if you have foo=bar in a definition file, this assertion could fire because when symbols are read from file they could be mangled. It seems that due to historical reasons underscore mangling scheme is really ad-hoc, and I cannot find a clean way to handle this. I had to just de-mangle symbols to search again. llvm-svn: 297357
2017-03-09 12:47:33 +08:00
# RUN: llvm-objdump -p %t.dll | FileCheck -check-prefix=CHECK7 %s
# CHECK7: Export Table:
# CHECK7: DLL name: export32.test.tmp.dll
# CHECK7: Ordinal RVA Name
# CHECK7-NEXT: 0 0
# CHECK7-NEXT: 1 0
# CHECK7-NEXT: 2 0x1010 foo
[yaml2obj] Updating LLD tests to account for LLVM r273915 This removed the -format flag from yaml2obj in favor of YAML tags. llvm-svn: 273920
2016-06-28 04:17:08 +08:00
--- !COFF
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
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
...