October 2022 - Wine-GitLab - list.winehq.org

[PATCH 0/5] MR1134: ntdll: Use local unwinding reimplementations for Unix libraries on ARM/ARM64
by Martin Storsjö Oct. 22, 2022

Oct. 22, 2022

Currently, unwinding the unix libraries (or full ELF builds) requires having libunwind available. When starting up a wine environment, an exception of type `RPC_S_SERVER_UNAVAILABLE` gets thrown - and if libunwind isn't available, this breaks the startup. Thus, currently on ARM/ARM64, libunwind is essentially mandatory. Additionally, at least on ARM, libunwind seems brittle (commits in latest git master breaks the unwinding use cases in Wine, see e.g. https://github.com/libunwind/libunwind/pull/203#issuecomment-984126066. This MR tries to resolve all of this, by including the preexisting DWARF parser from x86_64 in the aarch64 version too. This bit was mostly quite straightforward. For ARM, libunwind has currently relied on DWARF debug info in the `.debug_frame` section, since Linux on ARM doesn't use DWARF for runtime unwinding. This MR adds ARM EHABI unwind opcodes where necessary, and adds a local reimplementation of an ARM EHABI/EXIDX/EXTBL unwinder, similar to the DWARF one. With these changes, unwinding on both ARM and ARM64 seems to work fine, even without libunwind. See the individual commit messages for more commentary on the decisions taken so far (I've tried to write up all relevant considerations there - it's a fair amount of commentery). A couple open questions: - So far, the shared DWARF code was put in a header, `dwarf.h`. Do you want to make this a proper standalone `.c` file too? - I wrote the ARM EHABI unwind code mostly with `stdint.h` types like `uint32_t`(as it's in the ntdll/unix directory anyway), but I can rewrite it with `DWORD` or similar if that's preferred. - The ARM EHABI opcodes are enabled for `defined(__arm__) && defined(__ELF__) && defined(__GNUC__) && !defined(__SEH__) && !defined(__ARM_DWARF_EH__)` - there's no define to check for for knowing it's used and enabled, but it has to be implicitly assumed if no other other unwind mechanism is signaled. - The `dl_iterate_phdr` function, used for finding the EXIDX section for locating ARM EHABI unwind info, is used within `#ifdef linux`. It might be available on other OSes too (like FreeBSD etc). Or should I go ahead and add a configure check for it? CC @julliard @rbernon @AndreRH -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1134

2 7

[PATCH 0/1] MR1128: msvcrt: Display message box in abort() in debug CRT only.
by Paul Gofman (＠gofman) Oct. 22, 2022

Oct. 22, 2022

As far as my testing goes, the message box is never shown on Windows when abort() is called with retail runtime is used, regardless of error mode and abort behaviour. That is not the case with _assert which still can show a dialog even in release mode. It happens rather often that an app meets the error condition during the process exit and that goes silent on Windows while we display the abort dialog on app's exit. The test program below shows that (and the same behaviour is, e. g., with ucrtbase vs ucrtbased). ``` #include <windows.h> #include <stdio.h> #include <stdlib.h> void CDECL _set_app_type(int app_type); #define D(name) static typeof(name) *p_##name #define L(name) p_##name = (void *)GetProcAddress(hdll, #name); if (!p_##name) printf("NULL %s.\n", #name) D(abort); D(_set_app_type); D(_set_abort_behavior); D(_set_error_mode); int main(int argc, char *argv[]) { HMODULE hdll = LoadLibraryA("msvcrt.dll"); printf("hdll %p.\n", hdll); L(_set_app_type); if (!p__set_app_type) if (!(p__set_app_type = (void *)GetProcAddress(hdll, "__set_app_type"))) printf("NULL p__set_app_type.\n"); L(abort); L(_set_abort_behavior); L(_set_error_mode); p__set_app_type(2); if (p__set_abort_behavior) p__set_abort_behavior(_WRITE_ABORT_MSG, _WRITE_ABORT_MSG); p__set_error_mode(_OUT_TO_MSGBOX); p_abort(); } ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1128

5 5

Re: [PATCH v9 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Martin Storsjö Oct. 22, 2022

Oct. 22, 2022

On Fri Oct 21 09:44:38 2022 +0000, Rémi Bernon wrote: > I suggested to do that so we can use these tokens in the macros, which > need to stringify their value for the `.cfi_escape` strings. Oh, I see - thanks, that makes sense. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_11683

1 0

[PATCH v11 0/6] MR1120: Add support for localized functions in msvcrt dlls
by Bartosz Kosiorek (＠gang65) Oct. 22, 2022

Oct. 22, 2022

-- v11: msvcrt: Add _ismbstrail_l implementation. msvcrt: Add _ismbslead_l implementation. msvcrt: fix error handling for _mbscmp_l msvcrt: Add _mbclen_l implementation. msvcrt: Add _mbsicmp_l implementation. msvcrt: Add _mbschr_l implementation. https://gitlab.winehq.org/wine/wine/-/merge_requests/1120

4 12

Re: [PATCH v9 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Rémi Bernon Oct. 22, 2022

Oct. 22, 2022

On Fri Oct 21 09:29:30 2022 +0000, Martin Storsjö wrote: > Out of curiosity - was there any specific reason for changing these > enums into defines (or was this maybe an artifact from how this patch > evolved from earlier forms)? I suggested to do that so we can use these tokens in the macros, which need to stringify their value for the `.cfi_escape` strings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_11674

1 0

Re: [PATCH v9 0/1] MR1065: ntdll: Add CFI unwind info to __wine_syscall_dispatcher (x86_64)
by Martin Storsjö Oct. 22, 2022

Oct. 22, 2022

Martin Storsjö (@mstorsjo) commented about dlls/ntdll/unix/signal_x86_64.c: > - DW_OP_xderef_size = 0x95, > - DW_OP_nop = 0x96, > - DW_OP_push_object_address = 0x97, > - DW_OP_call2 = 0x98, > - DW_OP_call4 = 0x99, > - DW_OP_call_ref = 0x9a, > - DW_OP_form_tls_address = 0x9b, > - DW_OP_call_frame_cfa = 0x9c, > - DW_OP_bit_piece = 0x9d, > - DW_OP_lo_user = 0xe0, > - DW_OP_hi_user = 0xff, > - DW_OP_GNU_push_tls_address = 0xe0, > - DW_OP_GNU_uninit = 0xf0, > - DW_OP_GNU_encoded_addr = 0xf1, > -}; > +#define DW_CFA_advance_loc 0x40 Out of curiosity - was there any specific reason for changing these enums into defines (or was this maybe an artifact from how this patch evolved from earlier forms)? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_11673

1 0

Re: [PATCH v2 0/5] MR1126: Spelling and trailing linefeed fixes.
by Jan Sikorski (＠jsikorski) Oct. 22, 2022

Oct. 22, 2022

Jan Sikorski (@jsikorski) commented about dlls/dbghelp/dwarf.c: > } > > /* Dwarf tends to keep the structure of the C/C++ program, and emits DW_TAG_lexical_block > - * for every block in source program. > + * for every block the in source program. in the ;) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1126#note_11664

1 0

[PATCH 0/2] MR1133: Get rid of home grown allocator in DbgHelp.
by eric pouech (＠epo) Oct. 22, 2022

Oct. 22, 2022

Replace DbgHelp's internal memory allocator with heap functions: - slight improvement in speed (~ 1 to 2 %) - ability to reallocate chunks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1133

3 3

Re: [PATCH v2 0/1] MR1114: ntdll/tests: Force alignment of output structures.
by eric pouech (＠epo) Oct. 22, 2022

Oct. 22, 2022

On Thu Oct 20 17:51:23 2022 +0000, **** wrote: > Zebediah Figura replied on the mailing list: > ``` > On 10/20/22 03:54, Eric Pouech wrote: > > From: Eric Pouech <eric.pouech(a)gmail.com> > > > > Some Windows version expect output to be aligned on 4 bytes. > > > > Notes (from i386 and x86_64 tests): > > - MSVC and Mingw/gcc don't layout the two variables (sdki, sdki_ex) > > the same way. > > - MSVC aligns each variable on 4-byte boundary, > > - MingW/GCC stores them in a 8-byte chunk, but starting from the > > end of the buffer: hence none of them is on a 4-byte boundary. > > > > So, fixing the alignment of variables is not sufficient to > > workaround the compilers' discrepancy on all source code. > > > > I didn't find a generic way to align on 4 bytes structures of size > > smaller than 4 bytes (apart from adding the DECLSPEC_ALIGN to > > each of the offending structures, likely not that many though). > > Ideas welcomed. > Should we put those structs in pshpack4/poppack in the header? (They > aren't defined anywhere publicly on Windows, so we can't compare there.) > ``` from the testbot results, it seems that only W8 and early versions of W10 return errors on pointers not aligned on 4-byte; newer versions of W10 happily handle calls with unaligned pointers so I considered that the "default" is to support non aligned access, but this requires adapting the tests to workaround limitations (not to say bug) in W8/early W10 versions rather than to put it inside the structure declaration -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1114#note_11659

1 0

[PATCH v2 0/1] MR14: include: Add missing types in vkd3d_d3d12.idl.
by Biswapriyo Nath (＠Biswa96) Oct. 22, 2022

Oct. 22, 2022

-- v2: include: Add missing types in vkd3d_d3d12.idl. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/14

4 7