Using a dedicated exit jmpbuf and removing the need for assembly
routines.
When Wine handles an exception in unix code, we return to user mode by
jumping to the last syscall frame. This can leave some pthread cancel
cleanups registered, in the pthread internal linked list, and at the
same time later overwrite the stack frame they were registered for.
In the same way, jumping to the exit frame on thread exit or abort, can
also leave some cleanup handlers registered for invalid stack frames.
Depending on the implementation, calling pthread_exit will cause all the
registered pthread cleanup handlers to be called, possibly jumping back
to now overwritten stack frames and causing segmentation faults.
Exiting a pthread normally, by returning from its procedure, or calling
exit(0) for the main thread doesn't run pthread_exit and doesn't call
cleanup handlers, avoiding that situation.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
### Additional note:
For robustness, we should probably try to execute these cleanup handlers
when unwinding the stack frames, as we would otherwise leave pthread
objects in a potential problematic state (like a mutex locked, etc).
It is however hard to do so when the handlers are registered from some C
code: pthread C implementation is done by calling some internal pthread
functions to register the handlers, and they aren't registered as
standard unwind handlers.
Only pthread_cancel and pthread_exit can unwind and call / unregister
the C handlers, but interrupting that procedure, for instance calling
setjmp / longjmp from withing our own handler isn't supported.
From C++ code, pthread cleanup handlers are registered through C++ class
constructors / destructors, and it would then be possible to partially
unwind and call them at the same time.
--
v8: ntdll: Remove now unnecessary arch-specific exit frame.
ntdll: Avoid calling pthread_exit on thread exit.
ntdll: Return entry and suspend from server_init_process_done.
ntdll: Create a pthread for the main thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1088
Using a dedicated exit jmpbuf and removing the need for assembly
routines.
When Wine handles an exception in unix code, we return to user mode by
jumping to the last syscall frame. This can leave some pthread cancel
cleanups registered, in the pthread internal linked list, and at the
same time later overwrite the stack frame they were registered for.
In the same way, jumping to the exit frame on thread exit or abort, can
also leave some cleanup handlers registered for invalid stack frames.
Depending on the implementation, calling pthread_exit will cause all the
registered pthread cleanup handlers to be called, possibly jumping back
to now overwritten stack frames and causing segmentation faults.
Exiting a pthread normally, by returning from its procedure, or calling
exit(0) for the main thread doesn't run pthread_exit and doesn't call
cleanup handlers, avoiding that situation.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
### Additional note:
For robustness, we should probably try to execute these cleanup handlers
when unwinding the stack frames, as we would otherwise leave pthread
objects in a potential problematic state (like a mutex locked, etc).
It is however hard to do so when the handlers are registered from some C
code: pthread C implementation is done by calling some internal pthread
functions to register the handlers, and they aren't registered as
standard unwind handlers.
Only pthread_cancel and pthread_exit can unwind and call / unregister
the C handlers, but interrupting that procedure, for instance calling
setjmp / longjmp from withing our own handler isn't supported.
From C++ code, pthread cleanup handlers are registered through C++ class
constructors / destructors, and it would then be possible to partially
unwind and call them at the same time.
--
v7: ntdll: Remove now unnecessary arch-specific exit frame.
ntdll: Avoid calling pthread_exit on thread exit.
ntdll: Return entry and suspend from server_init_process_done.
ntdll: Create a pthread for the main thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1088
--
v3: vkd3d-shader/hlsl: Add functions to the global list inside the func_prototype rule.
vkd3d-shader/hlsl: Use the original hlsl_ir_function_decl struct rather than allocating a new one for each definition.
vkd3d-shader/hlsl: Put synthetic variables into a dummy scope.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77
Because of the change introduced in f21693b2, SM1 scalars and vectors were not longer getting the correct writemask when they are allocated, so this is fixed.
Also, the mapping of sm1 src register swizzles is moved outside `write_sm1_instruction()` since there are some instructions that don't do this, remarkably dp2add. This is fixed.
Before the last patch we are writing the operation as:
```
dp2add r0.x, r1.x, r0.x, r2.x
```
and now it is:
```
dp2add r0.x, r1.xyxx, r0.xyxx, r2.x
```
dp2add now has its own function, `write_sm1_dp2add()`, since it seems to
be the only instruction with this structure.
Ideally we would be using the default swizzles for the first two src arguments:
```
dp2add r0.x, r1, r0, r2.x
```
since, according to native's documentation, these are supported for all sm < 4.
But using default swizzles whenever is possible -- along with following the conversion of repeating the
last component of the swizzle when fewer than 4 components are to be
specified -- has a higher scope. Probably would involve modifying
`hlsl_swizzle_from_writemask()` and `hlsl_map_swizzle()`.
--
v2: vkd3d-shader/hlsl: Fix SM1 dp2add swizzles.
vkd3d-shader/hlsl: Map SM1 src swizzles outside write_sm1_instruction().
vkd3d-shader/hlsl: Set writemasks correctly for SM1 scalar and vector types.
vkd3d-shader/hlsl: Expect component count in allocate_register().
vkd3d-shader/hlsl: Rename 'component_count' arguments to 'reg_size'.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/81
On Mon Feb 6 15:36:14 2023 +0000, Timo Zuccarello wrote:
> Is there anything I can help with? I obviously have a bit of a personal
> interest in having this "fixed" finally.
Well if you feel like it, you can always have a look at the MR and review the changes.
I also opened https://gitlab.winehq.org/wine/wine/-/merge_requests/2122 with the complete changes, if you want to give it a try, and confirm that it does the right thing for you as well. I've done a bit of testing but I don't often use any very fancy keyboard layout either.
Then I suspect that what's expected here is actually a bit more wider testing, so probably I should try to get this into Wine Staging or Proton first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23264
Not completely sure if it's worth having for 8.0, but opening this to share the target I'm trying to reach.
--
v6: ntdll: Add a thread-specific category group cache.
ntdll: Use atomics and lock-free list for category groups.
ntdll: Implement Low Fragmentation Heap frontend.
ntdll: Count allocations and automatically enable LFH.
ntdll: Increase heap block tail_size capacity to 16 bits.
ntdll: Implement HeapCompatibilityInformation.
ntdll: Fix HeapWalk with empty uncommitted consecutive subheaps.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1628
WinRT apps check if the Windows theme is set to dark mode through IUISettings3::GetColorValue().
An option needs to be added to Winecfg to enable dark mode support, which just sets the registry key AppsUseLightTheme to 0 for dark mode and 1 for light mode. It will have to be in a separate merge request. Also, not sure if a dark mode checkbox should be added or if dark mode should be automatically set based on the loaded theme in Wine. Though, for the latter there needs to be a property that returns the mode of the theme. Name alone might not be sufficient.
--
v3: windows.ui/tests: Add IUISettings3::GetColorValue() tests.
windows.ui: Implement IUISettings3::GetColorValue().
windows.ui: Add IUISettings3 stub interface.
windows.ui: Add stub DLL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2103