If building lld without x86 support, tests that require that support should
be treated as unsupported, not errors.
Tested using:
1. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64;X86'
make check-lld
=>
Expected Passes : 1406
Unsupported Tests : 287
2. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64'
make check-lld
=>
Expected Passes : 410
Unsupported Tests : 1283
Patch by Joel Jones
Differential Revision: https://reviews.llvm.org/D47748
llvm-svn: 334095
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
In MinGW configurations (GCC, or clang with a *-windows-gnu target),
the -export directives in the object file contains the undecorated
symbol name, while it is decorated in MSVC configurations. (On the
command line, link.exe takes an undecorated symbol name for the
-export argument though.)
Differential Revision: https://reviews.llvm.org/D37772
llvm-svn: 313174
Joel Jones