- wine-gitlab - winehq.org

[PATCH 0/6] MR28: Support length(), int division and int absolute value.
by Giovanni Mascellani (＠giomasce) 17 Oct '22

17 Oct '22

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/28

4 8

[PATCH v2 0/1] MR18: include: Use __MINGW_PRINTF_FORMAT when compiling with MinGW.
by Zebediah Figura (＠zfigura) 17 Oct '22

17 Oct '22

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

4 5

[PATCH v3 0/2] MR1030: Add stubs and tests for GetConsoleOriginalTitleA/W
by Hugh McMaster (＠hmc) 17 Oct '22

17 Oct '22

-- v3: kernel32/tests: Add tests for GetConsoleOriginalTitleA/W() kernelbase: Add stubs for GetConsoleOriginalTitleA/W() https://gitlab.winehq.org/wine/wine/-/merge_requests/1030

3 3

[PATCH 0/1] MR1077: kernel32/tests: Remove tests comparing expected output in certain functions
by Hugh McMaster (＠hmc) 17 Oct '22

17 Oct '22

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

2 1

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon (＠rbernon) 17 Oct '22

17 Oct '22

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

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon (＠rbernon) 17 Oct '22

17 Oct '22

Rémi Bernon (@rbernon) commented about dlls/ntdll/unix/signal_x86_64.c: > + > +#define __ASM_CFI_REG_IS_AT_OFFSET2_FROM_RCX(REG, OFFSET1, OFFSET2) \ > + __ASM_CFI_REG_IS_AT_OFFSET2_FROM_BREG(REG, __ASM_CFI_DW_OP_breg2, OFFSET1, OFFSET2) > + > +#define __ASM_CFI_REG_IS_AT_OFFSET1_FROM_RCX(REG, OFFSET) \ > + __ASM_CFI_REG_IS_AT_OFFSET1_FROM_BREG(REG, __ASM_CFI_DW_OP_breg2, OFFSET) > + > +#define __ASM_CFI_CFA_IS_AT_OFFSET_FROM_RBP(OFFSET) \ > + __ASM_CFI_CFA_IS_AT_OFFSET1_FROM_BREG(__ASM_CFI_DW_OP_breg6, OFFSET) > + > +#define __ASM_CFI_CFA_IS_AT_OFFSET_FROM_RSP(OFFSET) \ > + __ASM_CFI_CFA_IS_AT_OFFSET1_FROM_BREG(__ASM_CFI_DW_OP_breg7, OFFSET) > + > +#define __ASM_CFI_CFA_IS_AT_OFFSET_FROM_RCX(OFFSET1, OFFSET2) \ > + __ASM_CFI_CFA_IS_AT_OFFSET2_FROM_BREG(__ASM_CFI_DW_OP_breg2, OFFSET1, OFFSET2) > + What about something simpler like, 1) #define the `DW_` constants above in the file instead of the enums, and 2) re-use them here in the expressions, with something like: ```c #define DW_OP_rcx DW_OP_breg2 #define DW_OP_rbp DW_OP_breg6 #define DW_OP_rsp DW_OP_breg7 #define DW_REG_rbx 0x03 #define DW_REG_rsi 0x04 #define DW_REG_rdi 0x05 #define DW_REG_rbp 0x06 #define DW_REG_rsp 0x07 #define DW_REG_r12 0x0c #define DW_REG_r13 0x0d #define DW_REG_r14 0x0e #define DW_REG_r15 0x0f #define DW_REG_rip 0x10 #define __ASM_CFI_STR(...) #__VA_ARGS__ #define __ASM_CFI_ESC(...) __ASM_CFI(".cfi_escape " __ASM_CFI_STR(__VA_ARGS__) "\n\t") #define __ASM_CFI_CFA_IS_AT(base, lo, hi) __ASM_CFI_ESC(DW_CFA_def_cfa_expression, 0x04, DW_OP_ ## base, lo, hi, DW_OP_deref) #define __ASM_CFI_REG_IS_AT(reg, base, lo, hi) __ASM_CFI_ESC(DW_CFA_expression, DW_REG_ ## reg, 0x03, DW_OP_ ## base, lo, hi) ``` And use that below as `__ASM_CFI_CFA_IS_AT(rcx,0x88,0x01)`, `__ASM_CFI_REG_IS_AT(rip,rcx,0xf0,0x00)`, etc... I think using two bytes offsets everywhere simplifies the macros, although we'll need a bit more offset mangling by hand to encode them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_10938

1 0

[PATCH 0/5] MR1072: comctl32: preparation for HPROPSHEETPAGE structure layout changes
by Piotr Caban (＠piotr) 17 Oct '22

17 Oct '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1072

4 9

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Florian Kübler (＠florian-kuebler) 17 Oct '22

17 Oct '22

>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

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon (＠rbernon) 17 Oct '22

17 Oct '22

> > 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

1 0

Re: [PATCH v2 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Florian Kübler (＠florian-kuebler) 17 Oct '22

17 Oct '22

>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

1 0

2025

2024

2023

2022

wine-gitlab