Run C++ global/static destructors during DLL_PROCESS_DETACH while other
other dllimport functions they may want to call are still viable. While
windows imposes many restrictions on what may be done in such destructors
(given that the run inside the loader lock), there are lots of legal and
useful kernel32 functions like DestroyCriticalSection, DeleteAtom, TlsFree,
etc that are both useful and legal. Currently this does not work for builtin
modules because all the Win32 structures are discarded well before
NtUnmapViewOfSection finally does the dlllose.
Even for a winelib .dll.so module, it would be preferable for destructors
to execute during process_detach (before wine tears down the MODREF
and detaches dependant dlls), rather than be left until after the last
NtUnmapViewOfSection (when we finally reach dlclose)
Therefore, winegcc now always uses the DllMainCRTStartup entry point
unless you specify your own --entry=func. Previously it did this only for
PE modules using msvcrt. Making this default consistent matches cl.exe,
which also always defaults to _DllMainCRTStartup unless overridden by /entry:foo
https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symb…
The ELF version of winecrt0.a now provides a DllMainCRTStartup which,
per the Itanium ABI that is in practice what is used by gcc and clang,
performs this this destruction by calling __cxa_finalize(&__dso_handle)..
This libc function is required to be idempotent, so it's OK that dlclose
still calls it again later (there will just be no further work to do).
Multiple calls to __cxa_finalize shall not result in calling termination
function entries multiple times; the implementation may either remove
entries or mark them finished.
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#dso-dtor-runtime-api
This has two main effects; it moves ELF destructors earlier (before imports
are unmapped), and it moves them inside the Nt loader lock. Being earlier
was the intended goal, and moving them inside the lock seems fine. Any Win32
API calls in destructors are just being subjected to the same lock hierarchy
rules as usual on windows (MSVC also runs destructors from DllMainCrtStartup)
https://docs.microsoft.com/en-us/cpp/build/run-time-library-behavior?view=m…
And any purely-ELF destructors that happen to also run earlier should never
call functions exported from wine (and thus don't care about ntdll's locks).
--
v3: winecrt0: run C++ object destructors during module unload.
https://gitlab.winehq.org/wine/wine/-/merge_requests/752
Follow-up to !600.
--
v2: wineoss: Switch to mmdevapi's unixlib.h.
wineoss: Adapt "get_position_params" struct to mmdevapi's.
wineoss: Adapt "get_frequency_params" struct to mmdevapi's.
wineoss: Adapt "create_stream_params" struct to mmdevapi's.
wineoss: Adapt "test_connect_params" struct to mmdevapi's.
wineoss: Drop "oss_" prefix in unixlib enum, apply it to the functions instead.
mmdevapi: Integrate wineoss's additions in unixlib.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/799
Follow-up to !600.
---
The version check logic is removed because redundant.
`SNDCTL_SYSINFO` was introduced in OSS 4.0: [oss4white.pdf](/uploads/e85c3196b611560db849cfac9e158bd2/oss4white.pdf)
The `ioctl()` call fails with OSS 3.x.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/799
This avoids an eventual stack overflow in exception-heavy applications.
Important note: when using the experimental Wow64 support on Linux, this change causes a crash during exception handling when unix_funcs->unwind_builtin_dll is called.
The call in dll/ntdll/signal_x86_64.c virtual_unwind() to unix_funcs->unwind_builtin_dll() should be commented out and replaced with 'status = STATUS_UNSUCCESSFUL;'.
This is along the same lines as needing to comment out the unix_funcs->init_builtin_dll() call for Wow64.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/802