February 2017 - Wine-Devel - list.winehq.org

Re: [v4 3/4] ntdll: Save rdi and rsi in raise_func_trampoline.
by Sebastian Lackner Feb. 13, 2017

Feb. 13, 2017

On 12.02.2017 23:41, Andrew Wesie wrote: > On Windows, RDI and RSI are callee-saved registers, but on Linux > they are caller-saved registers. As such, raise_func_trampoline > needs to explicitly unwind them. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/signal_x86_64.c | 12 +++++++++--- > dlls/ntdll/tests/exception.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 51 insertions(+), 3 deletions(-) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index d2b040e..2370cf4 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2092,9 +2092,11 @@ NTSTATUS context_from_server( CONTEXT *to, const context_t *from ) > extern void raise_func_trampoline( EXCEPTION_RECORD *rec, CONTEXT *context, raise_func func ); > __ASM_GLOBAL_FUNC( raise_func_trampoline, > __ASM_CFI(".cfi_signal_frame\n\t") > - __ASM_CFI(".cfi_def_cfa %rbp,144\n\t") /* red zone + rip + rbp */ > - __ASM_CFI(".cfi_rel_offset %rip,8\n\t") > - __ASM_CFI(".cfi_rel_offset %rbp,0\n\t") > + __ASM_CFI(".cfi_def_cfa %rbp,160\n\t") /* red zone + rip + rbp + rdi + rsi */ > + __ASM_CFI(".cfi_rel_offset %rip,24\n\t") > + __ASM_CFI(".cfi_rel_offset %rbp,16\n\t") > + __ASM_CFI(".cfi_rel_offset %rdi,8\n\t") > + __ASM_CFI(".cfi_rel_offset %rsi,0\n\t") > "call *%rdx\n\t" > "int $3") > > @@ -2111,6 +2113,8 @@ static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func fun > { > CONTEXT context; > EXCEPTION_RECORD rec; > + ULONG64 rsi; > + ULONG64 rdi; > ULONG64 rbp; > ULONG64 rip; > ULONG64 red_zone[16]; > @@ -2180,6 +2184,8 @@ static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func fun > rsp_ptr = (ULONG64 *)RSP_sig(sigcontext) - 16; > *(--rsp_ptr) = RIP_sig(sigcontext); > *(--rsp_ptr) = RBP_sig(sigcontext); > + *(--rsp_ptr) = RDI_sig(sigcontext); > + *(--rsp_ptr) = RSI_sig(sigcontext); > > /* now modify the sigcontext to return to the raise function */ > RIP_sig(sigcontext) = (ULONG_PTR)raise_func_trampoline; > diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c > index 183cf18..15973ce 100644 > --- a/dlls/ntdll/tests/exception.c > +++ b/dlls/ntdll/tests/exception.c > @@ -2073,6 +2073,47 @@ static DWORD run_exception_test(void *handler, const void* context, > return result; > } > > +static DWORD WINAPI unwind_rdi_rsi_handler( EXCEPTION_RECORD *rec, ULONG64 frame, > + CONTEXT *context, DISPATCHER_CONTEXT *dispatcher ) > +{ > + if (rec->ExceptionCode != STATUS_BREAKPOINT) > + return ExceptionContinueSearch; > + > + RtlUnwind( (PVOID)context->Rsp, (PVOID)(context->Rip + 1), rec, NULL ); Doesn't this suffer from the same problem as before? We might not have unwinding information for the unwind_rdi_rsi_handler function if it is not supported by all x86_64 compilers. Actually, I believe the change itself would also be acceptable even without tests. > + return ExceptionContinueSearch; > +} > + > +static const BYTE unwind_rdi_test_code[] = { > + 0x57, /* push %rdi */ > + 0x48, 0xc7, 0xc7, 0x55, 0x55, 0x55, 0x55, /* mov $0x55555555, %rdi */ > + 0xcc, /* int3 */ > + 0x48, 0x89, 0xf8, /* mov %rdi, %rax */ > + 0x5f, /* pop %rdi */ > + 0xc3, /* ret */ > +}; > + > +static const BYTE unwind_rsi_test_code[] = { > + 0x56, /* push %rsi */ > + 0x48, 0xc7, 0xc6, 0x33, 0x33, 0x33, 0x33, /* mov $0x33333333, %rsi */ > + 0xcc, /* int3 */ > + 0x48, 0x89, 0xf0, /* mov %rsi, %rax */ > + 0x5e, /* pop %rsi */ > + 0xc3, /* ret */ > +}; > + > +static void test_unwind_rdi_rsi(void) > +{ > + DWORD result; > + > + result = run_exception_test(unwind_rdi_rsi_handler, NULL, unwind_rdi_test_code, > + sizeof(unwind_rdi_test_code), 0); > + ok( result == 0x55555555, "expected %x, got %x\n", 0x55555555, result ); > + > + result = run_exception_test(unwind_rdi_rsi_handler, NULL, unwind_rsi_test_code, > + sizeof(unwind_rsi_test_code), 0); > + ok( result == 0x33333333, "expected %x, got %x\n", 0x33333333, result ); > +} > + > #endif /* __x86_64__ */ > > #if defined(__i386__) || defined(__x86_64__) > @@ -2653,6 +2694,7 @@ START_TEST(exception) > test_virtual_unwind(); > test___C_specific_handler(); > test_restore_context(); > + test_unwind_rdi_rsi(); > > if (pRtlAddFunctionTable && pRtlDeleteFunctionTable && pRtlInstallFunctionTableCallback && pRtlLookupFunctionEntry) > test_dynamic_unwind(); > -- 2.7.4 >

2 1

Re: [PATCH 01/14] mshtml/tests: Added body event setters tests.
by Marvin Feb. 13, 2017

Feb. 13, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=28575 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [v3 1/5] compobj.dll16: Implement CoLoadLibrary16 and CoFreeLibrary16.
by Alexandre Julliard Feb. 13, 2017

Feb. 13, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > +static HRESULT dll_list_add(LPCSTR library_name, struct open_dll **ret) > +{ > + struct open_dll *dll; > + HMODULE16 library; > + FARPROC16 DllCanUnloadNow; > + > + LIST_FOR_EACH_ENTRY(dll, &open_dll_list, struct open_dll, entry) > + { > + if(!strcasecmp(library_name, dll->library_name)) > + { > + TRACE("found %s already loaded\n", debugstr_a(library_name)); > + InterlockedIncrement(&dll->refs); > + *ret = dll; > + return S_OK; > + } > + } I don't think that comparing file names is appropriate for 16-bit, only the module name matters. You should probably call LoadLibrary16 in all cases. > + > + library = LoadLibrary16(library_name); > + if (!library) > + { > + ERR("couldn't load in-process dll %s\n", debugstr_a(library_name)); > + return E_ACCESSDENIED; /* FIXME: or should this be CO_E_DLLNOTFOUND? */ > + } You'd need to check again if the dll already exists, like the 32-bit code does. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [v7 5/6] user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown and add tests
by Fabian Maurer Feb. 13, 2017

Feb. 13, 2017

> msg.c:5233: Test failed: RedrawWindow:show_popup_extreme_location: > 12: the msg 0x001c was expected, but got msg 0x0085 instead Can't reproduce the error.

1 0

Re: [v7 5/6] user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown and add tests
by Marvin Feb. 13, 2017

Feb. 13, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=28573 Your paranoid android. === w7u (32 bit msg) === msg.c:5233: Test failed: RedrawWindow:show_popup_extreme_location: 12: the msg 0x001c was expected, but got msg 0x0085 instead

1 0

Re: advapi32: add LookupSecurityDescriptorPartsA/W stubs (resend)
by Sebastian Lackner Feb. 13, 2017

Feb. 13, 2017

On 13.02.2017 09:23, Austin English wrote: > Originally sent in November, with no comments: > https://source.winehq.org/patches/data/127657 > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41682 > > -- -Austin GPG: 14FB D7EA A041 937B > > > 0001-advapi32-add-LookupSecurityDescriptorPartsA-W-stubs.patch > > > From eebe82acd3fd4828a74b38c97f260ddfd2143b83 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Wed, 9 Nov 2016 21:43:18 -0600 > Subject: [PATCH] advapi32: add LookupSecurityDescriptorPartsA/W stubs > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/advapi32/advapi32.spec | 4 ++-- > dlls/advapi32/security.c | 24 ++++++++++++++++++++++++ > 2 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/dlls/advapi32/advapi32.spec b/dlls/advapi32/advapi32.spec > index 6c57c88..88d8634 100644 > --- a/dlls/advapi32/advapi32.spec > +++ b/dlls/advapi32/advapi32.spec > @@ -415,8 +415,8 @@ > @ stdcall LookupPrivilegeNameW(wstr ptr ptr ptr) > @ stdcall LookupPrivilegeValueA(ptr ptr ptr) > @ stdcall LookupPrivilegeValueW(ptr ptr ptr) > -# @ stub LookupSecurityDescriptorPartsA > -# @ stub LookupSecurityDescriptorPartsW > +@ stdcall LookupSecurityDescriptorPartsA(ptr ptr ptr ptr ptr ptr ptr) > +@ stdcall LookupSecurityDescriptorPartsW(ptr ptr ptr ptr ptr ptr ptr) > @ stdcall LsaAddAccountRights(ptr ptr ptr long) > @ stub LsaAddPrivilegesToAccount > # @ stub LsaClearAuditLog > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c > index 7e41c0a..b094015 100644 > --- a/dlls/advapi32/security.c > +++ b/dlls/advapi32/security.c > @@ -6087,3 +6087,27 @@ BOOL WINAPI SaferSetLevelInformation(SAFER_LEVEL_HANDLE handle, SAFER_OBJECT_INF > FIXME("(%p %u %p %u) stub\n", handle, infotype, buffer, size); > return FALSE; > } > + > +/****************************************************************************** > + * LookupSecurityDescriptorPartsA [ADVAPI32.@] > + */ > +DWORD WINAPI LookupSecurityDescriptorPartsA(TRUSTEEA *owner, TRUSTEEA *group, ULONG *access_count, > + EXPLICIT_ACCESSA *access_list, ULONG *audit_count, > + EXPLICIT_ACCESSA *audit_list, SECURITY_DESCRIPTOR *descriptor) > +{ > + FIXME("stub:%p %p %p %p %p %p %p\n", owner, group, access_count, > + access_list, audit_count, audit_list, descriptor); > + return ERROR_SUCCESS; It would be better to return failure when the stub doesn't do anything useful. > +} > + > +/****************************************************************************** > + * LookupSecurityDescriptorPartsW [ADVAPI32.@] > + */ > +DWORD WINAPI LookupSecurityDescriptorPartsW(TRUSTEEW *owner, TRUSTEEW *group, ULONG *access_count, > + EXPLICIT_ACCESSW *access_list, ULONG *audit_count, > + EXPLICIT_ACCESSW *audit_list, SECURITY_DESCRIPTOR *descriptor) > +{ > + FIXME("stub:%p %p %p %p %p %p %p\n", owner, group, access_count, > + access_list, audit_count, audit_list, descriptor); > + return ERROR_SUCCESS; > +} > -- 2.10.2 > > >

1 0

Re: qcap: Fix Query IID_PPin Interface return not found
by Andrew Eikum Feb. 13, 2017

Feb. 13, 2017

I wrote a quick test for this, and Windows doesn't behave this way. diff --git a/dlls/qcap/tests/qcap.c b/dlls/qcap/tests/qcap.c index d7fe288f4a..eed101cee3 100644 --- a/dlls/qcap/tests/qcap.c +++ b/dlls/qcap/tests/qcap.c @@ -1990,6 +1990,8 @@ static void test_COM_vfwcapture(void) todo_wine ok(hr == E_NOINTERFACE, "QueryInterface for IID_IAMVideoProcAmp failed: %08x\n", hr); hr = IBaseFilter_QueryInterface(bf, &IID_IOverlayNotify, (void**)&unk); ok(hr == E_NOINTERFACE, "QueryInterface for IID_IOverlayNotify failed: %08x\n", hr); + hr = IBaseFilter_QueryInterface(bf, &IID_IPin, (void**)&unk); + ok(hr == E_NOINTERFACE, "QueryInterface for IID_IPin failed: %08x\n", hr); while (IBaseFilter_Release(bf)); } On Thu, Feb 09, 2017 at 02:25:33PM +0800, 谢威 wrote: > ------------------ > ------------------ > > > > 武汉深之度科技有限公司 > Wuhan Deepin Technology Co., Ltd. > > 　　谢威　　 > > 手机：18038104349 > > > 武汉：武汉市光谷大道77号光谷金融港B18栋6楼 > 北京：北京市海淀区知春路锦秋国际大厦B座501室 > 上海：上海市长宁区愚园路1258号15A01室 > > > 官网：www.deepin.com　官博：深度操作系统 >

1 0

Re: [PATCH 01/12] mshtml/tests: Added body event setters tests.
by Marvin Feb. 13, 2017

Feb. 13, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=28563 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH 02/12] mshtml: Use inner window's event target for body element.
by Jacek Caban Feb. 13, 2017

Feb. 13, 2017

Hi, Please ignore the series for now, I will send a better version later. Jacek

1 0

Re: [PATCH 2/7] gdiplus: Initialize bitmap bits for reading in GdipBitmapLockBits when ImageFlagsReadOnly is specified
by Vincent Povirk Feb. 13, 2017

Feb. 13, 2017

This is very strange behavior. I think you at least need a comment making it clear this is intentional, and some tests. Your test in 7/7 isn't sufficient because it doesn't make it clear that the bits are being converted. I think you should test that the bitmap format is different from the one you use to lock, and add another test with ImageLockModeUserInputBuf. On Wed, Feb 8, 2017 at 9:56 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdiplus/image.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > >

2 1