RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 12:43:36 +01:00
Code Issues Projects Releases Wiki Activity
2ffa82223f
llvm-mirror/test/tools/llvm-dlltool/coff-decorated.def

39 lines
1.3 KiB
Modula-2
Raw Normal View History

[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386 Hook up the -k option (that in the original GNU dlltool removes the @n suffix from the symbol that the final executable ends up linked to). In llvm-dlltool, make sure that functions end up with the undecorate name type if this option is set and they are decorated. In mingw, when creating import libraries from def files instead of creating an import library as a side effect of linking a DLL, the symbol names in the def contain the stdcall/fastcall decoration (but no leading underscore). By setting the undecorate name type, a linker linking to the import library will omit the decoration from the DLL import entry. With this in place, mingw-w64 for i386 built with llvm-dlltool/clang produces import libraries that actually work. Differential Revision: https://reviews.llvm.org/D36548 llvm-svn: 310990
2017-08-16 07:18:36 +02:00
; RUN: llvm-dlltool -k -m i386 --input-def %s --output-lib %t.a
; RUN: llvm-readobj %t.a | FileCheck %s
; RUN: llvm-nm %t.a | FileCheck %s -check-prefix=CHECK-NM
LIBRARY test.dll
EXPORTS
CdeclFunction
StdcallFunction@4
@FastcallFunction@4
[COFF] Improve correctness of def parsing for GNU features The operator == used for exporting a function with a different name in the DLL compared to the name in the import library (which is useful for adding linker level aliases for function in the import library) is a feature distinct and different from the operator = used for exporting a function with a different name (both in import library and DLL) than in the implementation producing the DLL. When creating an import library using dlltool, from a def file that contains forwards (Func = OtherDll.Func), this shouldn't affect the produced import library, which should still behave just as if it was a normal exported function. This clears a lot of confusion and subtle misunderstandings, and avoids a parameter that was used to avoid creating weak aliases when invoked from lld. (This parameter was added previously due to the existing conflation of the two features.) Differential Revision: https://reviews.llvm.org/D46245 llvm-svn: 331859
2018-05-09 11:21:53 +02:00
StdcallAlias@4==StdcallFunction@4
[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386 Hook up the -k option (that in the original GNU dlltool removes the @n suffix from the symbol that the final executable ends up linked to). In llvm-dlltool, make sure that functions end up with the undecorate name type if this option is set and they are decorated. In mingw, when creating import libraries from def files instead of creating an import library as a side effect of linking a DLL, the symbol names in the def contain the stdcall/fastcall decoration (but no leading underscore). By setting the undecorate name type, a linker linking to the import library will omit the decoration from the DLL import entry. With this in place, mingw-w64 for i386 built with llvm-dlltool/clang produces import libraries that actually work. Differential Revision: https://reviews.llvm.org/D36548 llvm-svn: 310990
2017-08-16 07:18:36 +02:00
??_7exception@@6B@
[llvm-dlltool] Make sure to strip decorations from ExtName for renamed exports ExtName should not be decorated, just like Name. This avoids double decoration on symbols in import libraries that use = for renaming functions. (Weak aliases, which use ==, worked fine with respect to decoration.) Differential Revision: https://reviews.llvm.org/D66617 llvm-svn: 369747
2019-08-23 13:18:11 +02:00
StdcallExportName@4=StdcallInternalFunction@4
[llvm-dlltool] Handle external and internal names with differing decoration Also add a missed part of the test from SVN r369747. Differential Revision: https://reviews.llvm.org/D66996 llvm-svn: 370656
2019-09-02 15:28:16 +02:00
OtherStdcallExportName@4=CdeclInternalFunction
CdeclExportName=StdcallInternalFunction@4
[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386 Hook up the -k option (that in the original GNU dlltool removes the @n suffix from the symbol that the final executable ends up linked to). In llvm-dlltool, make sure that functions end up with the undecorate name type if this option is set and they are decorated. In mingw, when creating import libraries from def files instead of creating an import library as a side effect of linking a DLL, the symbol names in the def contain the stdcall/fastcall decoration (but no leading underscore). By setting the undecorate name type, a linker linking to the import library will omit the decoration from the DLL import entry. With this in place, mingw-w64 for i386 built with llvm-dlltool/clang produces import libraries that actually work. Differential Revision: https://reviews.llvm.org/D36548 llvm-svn: 310990
2017-08-16 07:18:36 +02:00
[test] [llvm-dlltool] Improve test strictness a little. NFC. llvm-svn: 370657
2019-09-02 15:28:21 +02:00
; CHECK: Name type: noprefix
; CHECK-NEXT: Symbol: __imp__CdeclFunction
; CHECK-NEXT: Symbol: _CdeclFunction
; CHECK: Name type: undecorate
; CHECK-NEXT: Symbol: __imp__StdcallFunction@4
; CHECK-NEXT: Symbol: _StdcallFunction@4
; CHECK: Name type: undecorate
; CHECK-NEXT: Symbol: __imp_@FastcallFunction@4
; CHECK-NEXT: Symbol: @FastcallFunction@4
; CHECK: Name type: name
; CHECK-NEXT: Symbol: __imp_??_7exception@@6B@
; CHECK-NEXT: Symbol: ??_7exception@@6B@
[COFF] Adjust how we flag weak externals This fixes PR36096. Originally based on a patch by Martell Malone. Differential Revision: https://reviews.llvm.org/D44357 llvm-svn: 337613
2018-07-20 22:48:29 +02:00
; CHECK-NM: W _StdcallAlias@4
[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386 Hook up the -k option (that in the original GNU dlltool removes the @n suffix from the symbol that the final executable ends up linked to). In llvm-dlltool, make sure that functions end up with the undecorate name type if this option is set and they are decorated. In mingw, when creating import libraries from def files instead of creating an import library as a side effect of linking a DLL, the symbol names in the def contain the stdcall/fastcall decoration (but no leading underscore). By setting the undecorate name type, a linker linking to the import library will omit the decoration from the DLL import entry. With this in place, mingw-w64 for i386 built with llvm-dlltool/clang produces import libraries that actually work. Differential Revision: https://reviews.llvm.org/D36548 llvm-svn: 310990
2017-08-16 07:18:36 +02:00
; CHECK-NM: U _StdcallFunction@4
[test] [llvm-dlltool] Improve test strictness a little. NFC. llvm-svn: 370657
2019-09-02 15:28:21 +02:00
; CHECK: Name type: undecorate
; CHECK-NEXT: Symbol: __imp__StdcallExportName@4{{$}}
; CHECK-NEXT: Symbol: _StdcallExportName@4{{$}}
; CHECK: Name type: undecorate
; CHECK-NEXT: Symbol: __imp__OtherStdcallExportName@4{{$}}
; CHECK-NEXT: Symbol: _OtherStdcallExportName@4{{$}}
; CHECK: Name type: noprefix
; CHECK-NEXT: Symbol: __imp__CdeclExportName
; CHECK-NEXT: Symbol: _CdeclExportName
Reference in New Issue Copy Permalink