This is necessary for math functions taking `long double` arguments to
work reliably, as by default, new threads have their x87 precision set
to 53 bits.
Note the x87 control word can't be set in the TLS callback. It gets
overwritten before the thread procedure begins execution. There is NO
workaround for the win32 thread model, other than requiring users to
call `_fpreset()` themselves.
Reference: https://sourceforge.net/p/mingw-w64/mailman/message/37084134/
Signed-off-by: Liu Hao <lh_mouse@126.com>
In the x86 case, mingw-w64 stdio functions use 64-bit division, which
relies on certain routines in libgcc, and causes undefined references
under some circumstances.
Instead, the MS ones should be called, which are available immediately
and do not depend on libgcc. This was also the case prior to bfd33f6c.
Reference: https://github.com/msys2/MINGW-packages/pull/6539
Signed-off-by: Liu Hao <lh_mouse@126.com>
the usage of this variable was removed in 13c9e28c0e commit
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: Liu Hao <lh_mouse@126.com>
It's forbidden in any UWP app but the same information can be gathered via
GetFileInformationByHandleEx.
It's used by gnutls (via gnulib).
Signed-off-by: Martin Storsjö <martin@martin.st>
When compiling with other compilers than MSVC, we always use the code
relying on USE_VEH_FOR_MSC_SETTHREADNAME.
The __try/__except check code is not modified as it relies on internal MSVC
dialect. With MSVC either USE_VEH_FOR_MSC_SETTHREADNAME was set but that code
wasn't use anyway (unchanged) or it wasn't set and we use the code (unchanged).
Without MSVC we always define USE_VEH_FOR_MSC_SETTHREADNAME so the other
variant of the code is used (unchanged).
Signed-off-by: Liu Hao <lh_mouse@126.com>
VirtualProtectFromApp is a fully functional replacement for cases when
not needing to touch code sections, and for other cases, the call
should fail - just like the previous stub that failed unconditionally.
This should be enough for fixing up runtime pseudo relocations for
code generated by LLVM (and possibly by GCC on x86_64), where all
fixed up references either are in normal data sections, or in .refptr
stubs.
Signed-off-by: Martin Storsjö <martin@martin.st>
The original libwinstorecompat is designed to be used with libmincore.
- CreateEventW is allowed
- CreateMutexW is allowed
- CreateSemaphoreW is allowed
- InitializeCriticalSection is allowed
- GetFileAttributes is allowed
- WaitForSingleObject is allowed
- GetTickCount is allowed
- SetUnhandledExceptionFilter is allowed
- TerminateProcess is allowed
- IsDBCSLeadByteEx is allowed
- SetErrorMode is allowed
- GetACP is allowed
- LocalAlloc/LocalFree are allowed
- Sleep/SleepEx are allowed
- SetFilePointer is allowed
- Tls functions are allowed
- GetConsoleOutputCP is allowed
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
To select the set of API's allowed by this library, define WINSTORECOMPAT
and build with _WIN32_WINNT >= _WIN32_WINNT_WIN10.
Signed-off-by: Martin Storsjö <martin@martin.st>
The previous form caused compiler warnings like "warning: extension used
[-Wlanguage-extension-token]" when built with clang.
Signed-off-by: Martin Storsjö <martin@martin.st>
It's needed by:
- getlogin() in mingwex
GetEnvironmentVariableA("USERNAME") gives the same information (tested on
win10 in cmd.exe and PowerShell).
No implementation provided when building winstorecompat for win8 as
GetEnvironmentVariableA is not allowed and GetUserNameEx requires -lsecur32.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since holding sema_b before aquiring waiters_count_lock_ can lead to deadlocks try to aquire waiters_count_lock_ opportunistically. If it fails then release sema_b and sched_yield() to give the other thread (which has aquired waiters_count_lock_ and is now waiting on sema_b) a chance to aquire sema_b before we retry the whole procedure.
Signed-off-by: Liu Hao <lh_mouse@126.com>
All other functions wait for `sema_b` with `waiters_count_lock_` locked.
The order of acquisition of these two things must happen in the same order
in all functions, otherwise deadlocks may happen.
The obvious fix is to make wait functions wait for the semaphore after
having locked `waiters_count_lock_`. However, before the wait, the critical
seciton must be unlocked, otherwise all the other threads will be blocked
on signal/broadcast functions. The now consequent wait and signal operations
on the semaphore have no other effect and can be removed.
From now on, waiting threads will update `waiters_count_` without attempting
to lock `sema_b`. If a wait function is called under the protection of the
external mutex, this was unnecessary; otherwise, scheduling behavior might be
unpredictable, which nevertheless still conforms to POSIX.
Signed-off-by: Liu Hao <lh_mouse@126.com>
WaitFor*() functions may time out earlier than requested
or later than requested. The "later" part is generally OK.
The "earlier" part is not.
Fix this by running the wait functions in a loop until the
time actually runs out, or the function returns a non-timeout
code.
This does not apply to cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).
This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.
The timeout checker uses the coarse GetTickCount64() because it's fast
and doesn't wrap around every 49 days.
Though it might not be accurate enough, let's go with it first.
On pre-Vista systems QueryPerformanceCounter() is used instead.
Signed-off-by: Liu Hao <lh_mouse@126.com>
If the caller provides ts_nsec in struct timespec,
we lose precision when converting that time to milliseconds
for our WaitFor*() calls. Make sure we round *up* when doing that
conversion, as otherwise the wait time will be *less* than the caller
expects. Users of pthreads on non-realtime systems are generally
OK with functions returning a bit later than requested. But timing out
*earlier* than the requested time is completely unexpected.
Signed-off-by: Liu Hao <lh_mouse@126.com>
libcxx defined `_LIBCPP_SAFE_STATIC` for static variable, if use winpthreads need `PTHREAD_*_INITIALIZER` constant, but current version have `reinterpret_cast` to convert integer initial value to pointer, `__attribute__((__require_constant_initialization__))` not allowed this define and causing compilation error..
Signed-off-by: SquallATF <squallatf@gmail.com>
Signed-off-by: Liu Hao <lh_mouse@126.com>
This only works for the local process. This uses structs from
winternl.h that, according to documentation, could change between
Windows versions.
While it legitimately could change, it hasn't so far (this layout
works with XP to 10), and for the Windows Store subset, this seems
like the most pragmatic solution.
llvm's libunwind uses this function for resolving dwarf exception
sections at runtime.
Signed-off-by: Martin Storsjö <martin@martin.st>
The libgcc stubs aren't necessary if building this when using
compiler-rt, after those stubs are available.
Just make the fake libgcc assembly file a no-op if targeting another
architecture.
Signed-off-by: Martin Storsjö <martin@martin.st>
