Fixes commit ee481ee9392c ("crt: Move ftime symbol definition from _ftime.c
to crt-aliases.def.in"). It added ftime symbol only to crt-aliases.def.in
which is not used by api-ms-win-crt-* def files for UCRT builds.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is mandatory on ARM64EC and also required on AArch64 for ARM64X builds.
Instead of extending the existing logic, unify it by always including it in mingwex.
Fill CF Guard fields with zeroes when CF Guard is not enabled in CRT builds. This
leverages existing LLD load config validation warnings to signal potential issues
if the user enables CF Guard while using a CRT that was not built with it.
In practice, this means load config will always be present in output images when using
LLD. Since ld.bfd does not support load config, it remains unaffected.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
The current MinGW implementation of Microsoft::WRL::ComPtr does not have
comparison operators. Attempting to compare two ComPtr instances will
implicitly convert the ComPtr to bool, and comparison is performed
against the resulting two bool values. This means that any two non-null
ComPtr instances compare equal.
This patch fixes this issue by adding the missing comparison operators.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The types are updated in alignment with the referenced documentation. The
declarations of `WHvEmulatorCreateEmulator()` etc. seem to be gone, but
they probably should not have been. Along with previous changes to
winhvplatformdefs.h, they now reference `WHV_RUN_VP_EXIT_CONTEXT` which is
only available when targeting x86-64. Therefore, they are also so declared
only when targeting x86-64.
Reference: b68e659cbe/virtualization/api/hypervisor-platform/headers/WinHvEmulation.h
Signed-off-by: LIU Hao <lh_mouse@126.com>
Function with name DllEntryPoint is entry point of the DLL library,
an alternative or aliased name to DllMainCRTStartup. So calling entry point
(DllEntryPoint) from entry point (DllMainCRTStartup) is just wrong.
Default DLL entry point function varies between compilers/linkers.
Borland C uses DllEntryPoint, GNU LD uses DllMainCRTStartup, MSVC link.exe
uses _DllMainCRTStartup.
The DLL application start function has same name DllMain.
Anyway, if the application is using own custom DLL entry point then it has
to pass appropriate compiler / linker parameters to omit inclusion of
standard library and/or startup files. Therefore removal of DllEntryPoint
should not cause big issues.
Signed-off-by: Martin Storsjö <martin@martin.st>
This macro is always defined by _mingw.h and its value is not checked by
any header file. So remove usage of this macro in .c files and dead code of
code paths when not set.
Signed-off-by: Martin Storsjö <martin@martin.st>
This macro is used only on few places in .c files, not in .h files.
So remove its usage and dead code.
Signed-off-by: Martin Storsjö <martin@martin.st>
Usage of separate static function __DllMainCRTStartup() is needed for MSVC
stack cookie handling as written in documentation for C Runtime Error R6035:
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/c-runtime-error-r6035
mingw-w64 does not support MSVC stack cookie handling, it was removed in
commit e6ac7e4230c9 ("crt: Remove the vestigial gs_support.c").
So merge static __DllMainCRTStartup() function directly into entry point
function DllMainCRTStartup().
Signed-off-by: Martin Storsjö <martin@martin.st>
For DLL builds, move calling __main(), _pei386_runtime_relocator() and
__mingw_init_ehandler() functions from __DllMainCRTStartup() into
_CRT_INIT() function.
This allow applications with custom entry point, which would call
_CRT_INIT() manually, to work correctly.
Also _CRT_INIT() contains guard which prevents duplicate code execution.
Signed-off-by: Martin Storsjö <martin@martin.st>
This will report runtime error if _CRT_INIT(DLL_PROCESS_ATTACH) is called
two or more times.
Without this guard the _CRT_INIT(DLL_PROCESS_ATTACH) may be unexpectely
called multiple times which will break __proc_attached counter and then
also the DLL_PROCESS_DETACH code path.
Startup code from Visual C++ runtime is doing same thing.
Signed-off-by: Martin Storsjö <martin@martin.st>
It is questionable which real issue can this guard detect or prevent,
but dll detach code from Visual C++ runtime is doing same thing.
And it makes sense that mingw-w64 would have compatible dll detach
logic with the Visual C++ dll detach code.
Signed-off-by: Martin Storsjö <martin@martin.st>
The variable __native_startup_lock should be volatile. But currently its
type is "volatile void *", which means that the dereferenced pointer value
is volatile, not the variable itself. Currently the compiler is throwing a
warning when the variable is used by InterlockedCompareExchangePointer() or
InterlockedExchangePointer() call. But all current usage do explicit cast
to (volatile PVOID *) which hides all warnings.
Existing type:
volatile PVOID * = void * volatile *
Before this change:
typeof(&__native_startup_lock) = void volatile **
After this change:
typeof(&__native_startup_lock) = void * volatile *
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit also removes macros, types and pragmas which are either defined
indirectly or unused.
Co-authored-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
Previously, these were only declared for C99 or C++. To avoid complication in
tchar.h, they are now declared unconditionally.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Explicitly include pthread_signal.h from pthread.h when compiling with MSVC.
Signed-off-by: Kirill Makurin <maiddaisuki@outlook.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
It should set the exception bits, rather than the exception mask bits.
Code on line 38-41 does the correct operation to the x87 status bits.
Signed-off-by: LIU Hao <lh_mouse@126.com>
