With this commit the following functions were implemented:
- _mbsupr_s_l - converts multibyte string to uppercase, by using specified locale that's passed in.
- _mbslwr_s_l - converts multibyte string to lowercase, by using specified locale that's passed in.
- _mbctolower_l - converts multibyte uppercase character to lowercase character, by using specified locale that's passed in.
- _mbctoupper_l - converts multibyte lowercase character to uppercase character, by using specified locale that's passed in.
More information about these methods are available at:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strupr-s-…
After applying the patch the crash of the ChessBase application was fixed.
More information:
https://bugs.winehq.org/show_bug.cgi?id=45273
--
v3: msvcrt: implement missing CRT functions to fix ChessBase 14 crash
https://gitlab.winehq.org/wine/wine/-/merge_requests/1080
With this commit the following functions were implemented:
- _mbsupr_s_l - converts multibyte string to uppercase, by using specified locale that's passed in.
- _mbslwr_s_l - converts multibyte string to lowercase, by using specified locale that's passed in.
- _mbctolower_l - converts multibyte uppercase character to lowercase character, by using specified locale that's passed in.
- _mbctoupper_l - converts multibyte lowercase character to uppercase character, by using specified locale that's passed in.
More information about these methods are available at:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strupr-s-…
After applying the patch the crash of the ChessBase application was fixed.
More information:
https://bugs.winehq.org/show_bug.cgi?id=45273
--
v2: msvcrt: implement missing CRT functions to fix ChessBase 14 crash
https://gitlab.winehq.org/wine/wine/-/merge_requests/1080
With this commit the following functions were implemented:
- _mbsupr_s_l - converts multibyte string to uppercase, by using specified locale that's passed in.
- _mbslwr_s_l - converts multibyte string to lowercase, by using specified locale that's passed in.
- _mbctolower_l - converts multibyte uppercase character to lowercase character, by using specified locale that's passed in.
- _mbctoupper_l - converts multibyte lowercase character to uppercase character, by using specified locale that's passed in.
More information about these methods are available at:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strupr-s-…
After applying the patch the crash of the ChessBase application was fixed.
More information:
https://bugs.winehq.org/show_bug.cgi?id=45273
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1080
--
v2: vkd3d-shader/hlsl: Parse UAV types.
vkd3d-shader/hlsl: Parse texture index expressions.
vkd3d-shader/hlsl: Cast array indices inside of add_array_load().
tests: Add a basic shader test for typed UAV loads.
tests: Add a basic shader test for compute shaders.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/30
--
v2: uiautomationcore: Add support for getting HWND providers to uia_node_from_lresult().
uiautomationcore: Add support for getting HWND providers to UiaNodeFromProvider().
uiautomationcore: Determine provider type for nested node providers.
uiautomationcore: Add support for multiple providers on a single HUIANODE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1052
--
v2: ntdll/tests: Add more tests for \Device\NamedPipe and \Device\NamedPipe\.
ntdll/tests: Add tests for exotic pipe names.
kernel32/tests: Add test for pipe name with a trailing backslash.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1070
Hello, this is the first part of a patch series to support:
* Complex broadcasts.
* Complex implicit casts between component-wise equal types.
* Complex explicit casts between component-wise compatible types.
This first part of the series includes mostly tests.
Following patches in: https://gitlab.winehq.org/fcasas/vkd3d/-/commits/complex_broadcasts_2/
This supersedes !16 .
--
v3: tests: Test explicit casts between types that are component-wise
tests: Test implicit casts between types that are equal component-wise.
vkd3d-shader/hlsl: Always go through implicit conversion in assignments.
tests: Test for invalid complex broadcasts.
tests: Rename structs for readability in broadcast test.
tests: Set ULPs to 2 in normalize() test.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/29
The default for MinGW is always ms_printf rather than gnu_printf, but if we are
using ucrtbase or ANSI stdio, we want gnu_printf.
--
v2: include: Use __MINGW_PRINTF_FORMAT when compiling with MinGW.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/18
The Windows versions of [Read|Write]ConsoleOutput[Attribute|Character]
appear to assign an uninitialized internal DWORD to the given pointer
address before returning.
As the functions fail (intentionally) in these tests, the value of the
DWORD is never set, so the tests end up comparing the expected value of
zero with random values.
This value of this test is very limited and is best removed.
Fixes https://bugs.winehq.org/show_bug.cgi?id=53686
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1077
Rémi Bernon (@rbernon) commented about dlls/ntdll/unix/signal_x86_64.c:
> "movq %gs:0x30,%rcx\n\t"
> "movq 0x328(%rcx),%rcx\n\t" /* amd64_thread_data()->syscall_frame */
> "popq 0x70(%rcx)\n\t" /* frame->rip */
> + __ASM_CFI(".cfi_adjust_cfa_offset -8\n\t")
> + // $rip = frame->rip // (*(0x70($rcx)))
I understand the point but I don't think we need to keep these comments. We also don't use C++-style comments.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10939
>Yes, in my case I'm mostly only interested in the case with DWARF debug info in PE files. The applications I'm working with usually don't have debug information anyway and I'm trying to get stack traces and tooling support for Wine code specifically.
Okay, yeah that makes a lot of sense now. Just to note that Windows "runtime function" unwind information was almost always available when we checked.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10931
> > FWIW this also works with Valgrind, and you might be interested in https://gitlab.winehq.org/wine/wine/-/merge_requests/1074 too.
>
> That is interesting. So, but do I see correctly that this only works, if the Windows Pe/Coff files, actually have **DWARF** unwind information embedded. Which is as far as I am aware only the case for cross-compilation with mingw, right?
> > I should probably add that it only does that when it has the debug info for the PE modules, this isn't currently well supported, and needs to be done somehow manually.
>
> Are you referring to the Windows unwind information (runtime function), or the DWARF information mentioned above? Our LLDB patch (which we hopefully upstream soon), as well as the libunwindstack implementation actually takes care of all kind of PE/Coff modules, and is able to use runtime function as well, as DWARF information.
Yes, in my case I'm mostly only interested in the case with DWARF debug info in PE files. The applications I'm working with usually don't have debug information anyway and I'm trying to get stack traces and tooling support for Wine code specifically.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10930
>Hmm, I need to think about that. When I said it fully works, I should maybe indicate that GDB doesn't usually display local variables for the first frame below the syscall, so maybe it's because of this even though it manages to catch up for lower frames.
As far as I remember, local variables were available in all frames in our case. It should be mostly because we specify callee-save registers right away when they get stored. Also it is likely, that if the computation in not correct in the first place, that it will catch up later, as there will be new unwind information mostly specifying "register foo is saved at that position on the stack".
>FWIW this also works with Valgrind, and you might be interested in https://gitlab.winehq.org/wine/wine/-/merge_requests/1074 too.
That is interesting. So, but do I see correctly that this only works, if the Windows Pe/Coff files, actually have **DWARF** unwind information embedded. Which is as far as I am aware only the case for cross-compilation with mingw, right?
>It's not exactly the `pushfl` but more that the dispatcher pops `rip` first, which effectively removes the return address from the stack, then `pushfl` overrides its value. It's not causing problems later because the dispatcher uses the poped `rip` value to return to the caller, but it temporarily confuses GDB stack unwinding. Maybe with your CFI instructions it's not required.
Right! And that is the reason why we don't need it, as we do specify "RIP" based on syscall frame and not based on CFA, right as it gets popped. I think that's another case, where it is actually better to do the `breg` instructions, as it gives you the freedom to specify some variables based on CFA and some based on register content.
>The reason I've been told, is that some DRMs are checking that the NT syscalls didn't touch the stack. I don't really know more.
Oh interesting. That makes a lot of sense, and our lives so much harder... :smile:
>Yes, it's already an issue for `perf` captures when you want stack traces that cross user and kernel stacks, and I don't really have any good solution for that. Having an optional working mode which would interleave kernel frames and user frames may be possible but it doesn't seem much tractable.
Yep, `perf` is actually using the same `perf_event_open` syscall that we are using. So it makes sense that we are observing the same issue. The "bruteforce" way we worked around with that, is to inject into the syscall dispatcher (using a uprobe) and always collect the "user-space" stack, then for the actual samples, make both stacks available to the unwinder. This obviously comes with a big performance hit, and might corrupt your performance characteristics. However, it actually turned out to be useful to find some issues.
An alternative solution, that we never ended up actually implementing would be to use a eBPF program for the sampling/stack collection. We could make it copy both stacks explicitly.
Obvious the more elegant solution would be, as you mentioned, to either have a switch in Wine to only have one stack, or alternatively, make it possible in perf_event_open, to collect both stacks. It would be be not the first time that Linux kernel has special handling for wine.
>I should probably add that it only does that when it has the debug info for the PE modules, this isn't currently well supported, and needs to be done somehow manually.
Are you referring to the Windows unwind information (runtime function), or the DWARF information mentioned above?
Our LLDB patch (which we hopefully upstream soon), as well as the libunwindstack implementation actually takes care of all kind of PE/Coff modules, and is able to use runtime function as well, as DWARF information.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10929