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/def-export-stdcall.s

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

125 lines
4.7 KiB
ArmAsm
Raw Normal View History

[LLD] Mark a number of x86 only tests to require x86 Noticed while testing for an out of tree target. There are probably more tests that should be so marked. I'm not sure who owns these tests so I've added a few names I recognise from the recent history. With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all! Differential Revision: https://reviews.llvm.org/D34685 llvm-svn: 308335
2017-07-19 02:40:50 +08:00
# REQUIRES: x86
Add test case for LLD/COFF for stdcall exports in .def files The .def file parser changes I reverted broke this test case, and exported "__imp__foo" instead of "__imp__foo@8". This was http://crbug.com/728726. llvm-svn: 304572
2017-06-03 01:48:06 +08:00
# RUN: llvm-mc -filetype=obj -triple=i686-windows-msvc %s -o %t.obj
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# RUN: echo -e "LIBRARY foo\nEXPORTS\n stdcall\n fastcall\n vectorcall\n _underscored" > %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 -entry:dllmain -dll -def:%t.def %t.obj -out:%t.dll -implib:%t.lib
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix UNDECORATED-IMPLIB %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 --coff-exports %t.dll | FileCheck -check-prefix UNDECORATED-EXPORTS %s
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# UNDECORATED-IMPLIB: Name type: noprefix
# UNDECORATED-IMPLIB-NEXT: __imp___underscored
# UNDECORATED-IMPLIB-NEXT: __underscored
# UNDECORATED-IMPLIB: Name type: undecorate
# UNDECORATED-IMPLIB-NEXT: __imp_@fastcall@8
# UNDECORATED-IMPLIB-NEXT: fastcall@8
# UNDECORATED-IMPLIB: Name type: undecorate
# UNDECORATED-IMPLIB-NEXT: __imp__stdcall@8
# UNDECORATED-IMPLIB-NEXT: _stdcall@8
# UNDECORATED-IMPLIB: Name type: undecorate
# UNDECORATED-IMPLIB-NEXT: __imp_vectorcall@@8
# UNDECORATED-IMPLIB-NEXT: vectorcall@@8
# UNDECORATED-EXPORTS: Name: _underscored
# UNDECORATED-EXPORTS: Name: fastcall
# UNDECORATED-EXPORTS: Name: stdcall
# UNDECORATED-EXPORTS: Name: vectorcall
# RUN: echo -e "LIBRARY foo\nEXPORTS\n _stdcall@8\n @fastcall@8\n vectorcall@@8" > %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 -entry:dllmain -dll -def:%t.def %t.obj -out:%t.dll -implib:%t.lib
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix DECORATED-IMPLIB %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 --coff-exports %t.dll | FileCheck -check-prefix DECORATED-EXPORTS %s
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# DECORATED-IMPLIB: Name type: name
# DECORATED-IMPLIB-NEXT: __imp_@fastcall@8
# DECORATED-IMPLIB-NEXT: @fastcall@8
[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode This fixes PR35733. Differential Revision: https://reviews.llvm.org/D41632 llvm-svn: 323036
2018-01-20 19:44:42 +08:00
# DECORATED-IMPLIB: Name type: name
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# DECORATED-IMPLIB-NEXT: __imp__stdcall@8
# DECORATED-IMPLIB-NEXT: _stdcall@8
# DECORATED-IMPLIB: Name type: name
# DECORATED-IMPLIB-NEXT: __imp_vectorcall@@8
# DECORATED-IMPLIB-NEXT: vectorcall@@8
# DECORATED-EXPORTS: Name: @fastcall@8
[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode This fixes PR35733. Differential Revision: https://reviews.llvm.org/D41632 llvm-svn: 323036
2018-01-20 19:44:42 +08:00
# DECORATED-EXPORTS: Name: _stdcall@8
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# DECORATED-EXPORTS: Name: vectorcall@@8
[COFF] Add support for the GNU ld flag --kill-at GNU ld has got a number of different flags for adjusting how to behave around stdcall functions. The --kill-at flag strips the trailing sdcall suffix from exported functions (which otherwise is included by default in MinGW setups). This also strips it from the corresponding import library though. That makes it hard to link to such an import library from code that calls the functions - but this matches what GNU ld does with this flag. Therefore, this flag is probably not sensibly used together with import libraries, but probably mostly when creating some sort of plugin, or if creating the import library separately with dlltool. Differential Revision: https://reviews.llvm.org/D44292 llvm-svn: 327561
2018-03-15 04:17:16 +08:00
# GNU tools don't support vectorcall at the moment, but test it for completeness.
# RUN: echo -e "LIBRARY foo\nEXPORTS\n stdcall@8\n @fastcall@8\n vectorcall@@8" > %t.def
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# RUN: lld-link -lldmingw -entry:dllmain -dll -def:%t.def %t.obj -out:%t.dll -implib:%t.lib
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix DECORATED-MINGW-IMPLIB %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 --coff-exports %t.dll | FileCheck -check-prefix DECORATED-MINGW-EXPORTS %s
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# DECORATED-MINGW-IMPLIB: Name type: name
# DECORATED-MINGW-IMPLIB-NEXT: __imp_@fastcall@8
# DECORATED-MINGW-IMPLIB-NEXT: fastcall@8
# DECORATED-MINGW-IMPLIB: Name type: noprefix
# DECORATED-MINGW-IMPLIB-NEXT: __imp__stdcall@8
# DECORATED-MINGW-IMPLIB-NEXT: _stdcall@8
[COFF] Add support for the GNU ld flag --kill-at GNU ld has got a number of different flags for adjusting how to behave around stdcall functions. The --kill-at flag strips the trailing sdcall suffix from exported functions (which otherwise is included by default in MinGW setups). This also strips it from the corresponding import library though. That makes it hard to link to such an import library from code that calls the functions - but this matches what GNU ld does with this flag. Therefore, this flag is probably not sensibly used together with import libraries, but probably mostly when creating some sort of plugin, or if creating the import library separately with dlltool. Differential Revision: https://reviews.llvm.org/D44292 llvm-svn: 327561
2018-03-15 04:17:16 +08:00
# GNU tools don't support vectorcall, but this test is just to track that
# lld's behaviour remains consistent over time.
# DECORATED-MINGW-IMPLIB: Name type: name
# DECORATED-MINGW-IMPLIB-NEXT: __imp_vectorcall@@8
# DECORATED-MINGW-IMPLIB-NEXT: vectorcall@@8
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
# DECORATED-MINGW-EXPORTS: Name: @fastcall@8
# DECORATED-MINGW-EXPORTS: Name: stdcall@8
[COFF] Add support for the GNU ld flag --kill-at GNU ld has got a number of different flags for adjusting how to behave around stdcall functions. The --kill-at flag strips the trailing sdcall suffix from exported functions (which otherwise is included by default in MinGW setups). This also strips it from the corresponding import library though. That makes it hard to link to such an import library from code that calls the functions - but this matches what GNU ld does with this flag. Therefore, this flag is probably not sensibly used together with import libraries, but probably mostly when creating some sort of plugin, or if creating the import library separately with dlltool. Differential Revision: https://reviews.llvm.org/D44292 llvm-svn: 327561
2018-03-15 04:17:16 +08:00
# DECORATED-MINGW-EXPORTS: Name: vectorcall@@8
[test] Fix a temp filename in a test from SVN r327561. NFC. An earlier file name accidentally slipped through into the committed version. llvm-svn: 327567
2018-03-15 04:31:31 +08:00
# RUN: lld-link -lldmingw -kill-at -entry:dllmain -dll -def:%t.def %t.obj -out:%t.dll -implib:%t.lib
[COFF] Add support for the GNU ld flag --kill-at GNU ld has got a number of different flags for adjusting how to behave around stdcall functions. The --kill-at flag strips the trailing sdcall suffix from exported functions (which otherwise is included by default in MinGW setups). This also strips it from the corresponding import library though. That makes it hard to link to such an import library from code that calls the functions - but this matches what GNU ld does with this flag. Therefore, this flag is probably not sensibly used together with import libraries, but probably mostly when creating some sort of plugin, or if creating the import library separately with dlltool. Differential Revision: https://reviews.llvm.org/D44292 llvm-svn: 327561
2018-03-15 04:17:16 +08:00
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix MINGW-KILL-AT-IMPLIB %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 --coff-exports %t.dll | FileCheck -check-prefix MINGW-KILL-AT-EXPORTS %s
[COFF] Add support for the GNU ld flag --kill-at GNU ld has got a number of different flags for adjusting how to behave around stdcall functions. The --kill-at flag strips the trailing sdcall suffix from exported functions (which otherwise is included by default in MinGW setups). This also strips it from the corresponding import library though. That makes it hard to link to such an import library from code that calls the functions - but this matches what GNU ld does with this flag. Therefore, this flag is probably not sensibly used together with import libraries, but probably mostly when creating some sort of plugin, or if creating the import library separately with dlltool. Differential Revision: https://reviews.llvm.org/D44292 llvm-svn: 327561
2018-03-15 04:17:16 +08:00
# RUN: lld-link -lldmingw -kill-at -entry:dllmain -dll %t.obj -out:%t.dll -implib:%t.lib
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix MINGW-KILL-AT-IMPLIB %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 --coff-exports %t.dll | FileCheck -check-prefix MINGW-KILL-AT-EXPORTS %s
[COFF] Add support for the GNU ld flag --kill-at GNU ld has got a number of different flags for adjusting how to behave around stdcall functions. The --kill-at flag strips the trailing sdcall suffix from exported functions (which otherwise is included by default in MinGW setups). This also strips it from the corresponding import library though. That makes it hard to link to such an import library from code that calls the functions - but this matches what GNU ld does with this flag. Therefore, this flag is probably not sensibly used together with import libraries, but probably mostly when creating some sort of plugin, or if creating the import library separately with dlltool. Differential Revision: https://reviews.llvm.org/D44292 llvm-svn: 327561
2018-03-15 04:17:16 +08:00
# MINGW-KILL-AT-IMPLIB: Name type: noprefix
# MINGW-KILL-AT-IMPLIB: __imp__fastcall
# MINGW-KILL-AT-IMPLIB-NEXT: _fastcall
# MINGW-KILL-AT-IMPLIB: Name type: noprefix
# MINGW-KILL-AT-IMPLIB-NEXT: __imp__stdcall
# MINGW-KILL-AT-IMPLIB-NEXT: _stdcall
# GNU tools don't support vectorcall, but this test is just to track that
# lld's behaviour remains consistent over time.
# MINGW-KILL-AT-IMPLIB: Name type: noprefix
# MINGW-KILL-AT-IMPLIB-NEXT: __imp__vectorcall
# MINGW-KILL-AT-IMPLIB-NEXT: _vectorcall
# MINGW-KILL-AT-EXPORTS: Name: fastcall
# MINGW-KILL-AT-EXPORTS: Name: stdcall
# MINGW-KILL-AT-EXPORTS: Name: vectorcall
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
Add test case for LLD/COFF for stdcall exports in .def files The .def file parser changes I reverted broke this test case, and exported "__imp__foo" instead of "__imp__foo@8". This was http://crbug.com/728726. llvm-svn: 304572
2017-06-03 01:48:06 +08:00
.def _stdcall@8;
.scl 2;
.type 32;
.endef
.globl _stdcall@8
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
.globl @fastcall@8
.globl vectorcall@@8
.globl __underscored
Add test case for LLD/COFF for stdcall exports in .def files The .def file parser changes I reverted broke this test case, and exported "__imp__foo" instead of "__imp__foo@8". This was http://crbug.com/728726. llvm-svn: 304572
2017-06-03 01:48:06 +08:00
_stdcall@8:
movl 8(%esp), %eax
addl 4(%esp), %eax
retl $8
[COFF] Fix exporting of functions starting with underscores, etc This fixes exporting functions in the following cases: - functions starting with an underscore in def files - functions starting with an underscore, via dllexport attributes, for mingw - fastcall and vectorcall functions when declared undecorated in def files - vectorcall functions when declared decorated in def files - stdcall functions when declared decorated in def files for mingw This still exports the stdcall functions with the wrong name in the normal msvc/link.exe mode, if declared with decoration in the def file though (this is not a regression though). Exporting functions via def files including decoration is not something I believe is routinely done though, but is tested to try to match link.exe's behaviour as far as easily possible. Differential Revision: https://reviews.llvm.org/D39170 llvm-svn: 316317
2017-10-23 17:08:24 +08:00
@fastcall@8:
movl 8(%esp), %eax
addl 4(%esp), %eax
retl $8
vectorcall@@8:
movl 8(%esp), %eax
addl 4(%esp), %eax
retl $8
__underscored:
ret
Add test case for LLD/COFF for stdcall exports in .def files The .def file parser changes I reverted broke this test case, and exported "__imp__foo" instead of "__imp__foo@8". This was http://crbug.com/728726. llvm-svn: 304572
2017-06-03 01:48:06 +08:00
.def _dllmain;
.scl 2;
.type 32;
.endef
.globl _dllmain
_dllmain:
retl