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

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
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: lld-link -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
# RUN: llvm-readobj -coff-exports %t.dll | FileCheck -check-prefix UNDECORATED-EXPORTS %s
# 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
# RUN: lld-link -entry:dllmain -dll -def:%t.def %t.obj -out:%t.dll -implib:%t.lib
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix DECORATED-IMPLIB %s
# RUN: llvm-readobj -coff-exports %t.dll | FileCheck -check-prefix DECORATED-EXPORTS %s
# 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
# RUN: llvm-readobj -coff-exports %t.dll | FileCheck -check-prefix DECORATED-MINGW-EXPORTS %s
# 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
# RUN: lld-link -lldmingw -kill-at -entry:dllmain -dll -def:%t.deco-mingw.def %t.obj -out:%t.dll -implib:%t.lib
# RUN: llvm-readobj %t.lib | FileCheck -check-prefix MINGW-KILL-AT-IMPLIB %s
# RUN: llvm-readobj -coff-exports %t.dll | FileCheck -check-prefix MINGW-KILL-AT-EXPORTS %s
# 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
# RUN: llvm-readobj -coff-exports %t.dll | FileCheck -check-prefix MINGW-KILL-AT-EXPORTS %s
# 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