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

Re: iphlpapi/tests: Add tests for GetUnicastIpAddressEntry (try 2)
by Marvin 05 Feb '17

05 Feb '17

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=28340 Your paranoid android. === build (build) === Make failed

1 0

Re: [v3 2/3] ntdll: Save rdi and rsi in raise_func_trampoline.
by Sebastian Lackner 05 Feb '17

05 Feb '17

On 05.02.2017 07:10, 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 af16cfd..8b85be7 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2067,9 +2067,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") > > @@ -2086,6 +2088,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]; > @@ -2155,6 +2159,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); Good catch! > > /* 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 dc8f1e2..80c22d0 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 ); Is it safe to assume that this will always work? Unwinding past the unwind_rdi_rsi_handler function might require unwinding information, but I'm not sure if we have that when compiling with mingw? I thought this was not implemented yet. On the testbot it still passed, probably because it was luckily compiled to a simple leaf function. > + 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 ); > +} > + > static DWORD WINAPI dr7_handler( EXCEPTION_RECORD *rec, ULONG64 frame, > CONTEXT *context, DISPATCHER_CONTEXT *dispatcher ) > { > @@ -2651,6 +2692,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(); >

1 0

Re: [v3 1/3] ntdll: Set Dr7 when saving context.
by Sebastian Lackner 05 Feb '17

05 Feb '17

On 05.02.2017 07:10, Andrew Wesie wrote: > This is a work-around so that Dr7 is initialized to a reasonable value. Before > it was just uninitialized memory. The test will fail without the work-around, > and shows a todo if Dr7 is zero. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/signal_x86_64.c | 1 + > dlls/ntdll/tests/exception.c | 121 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 122 insertions(+) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index f33fe4c..af16cfd 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -1692,6 +1692,7 @@ static void save_context( CONTEXT *context, const ucontext_t *sigcontext ) > context->u.FltSave = *FPU_sig(sigcontext); > context->MxCsr = context->u.FltSave.MxCsr; > } > + context->Dr7 = 0; > } > > Wouldn't it make more sense to add a proper implementation for all debug registers? We already have the signal_i386 code for an example how to do it, and other functions like NtGetContextThread also support querying the debug registers (even on x86_64). Best regards, Sebastian

2 2

Re: [v2 2/3] ntdll: Save rdi and rsi in raise_func_trampoline.
by Marvin 05 Feb '17

05 Feb '17

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=28326 Your paranoid android. === build (build) === Make failed

1 0

Re: [v2 1/3] ntdll: Set Dr7 when saving context.
by Marvin 05 Feb '17

05 Feb '17

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=28325 Your paranoid android. === build (build) === Make failed

1 0

GSoC Ideas page
by André Hentschel 04 Feb '17

04 Feb '17

Hi, I just did the GSoC 2017 application for Wine, please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Thanks!

3 2

Re: [3/3] wined3d: Upload textures if NO_DIRTY_UPDATE flag is set when locking dynamic textures.
by Marvin 04 Feb '17

04 Feb '17

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=28316 Your paranoid android. === w1064 (32 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Re: [1/3] d3d9/tests: Add LockRect tests with dynamic textures.
by Marvin 04 Feb '17

04 Feb '17

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=28313 Your paranoid android. === w1064 (32 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00000080 for no color attribute test. === w864 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 2/3] ntdll: Add partial NtQueryInformationThread(ThreadIsIoPending) implementation
by Piotr Caban 03 Feb '17

03 Feb '17

This patch is incorrect, please ignore it. Thanks, Piotr

1 0

Re: [PATCH 2/2] wined3d: Add support for SRCCOLOR2, INVSRCCOLOR2, SRCALPHA2 and INVSRCALPHA2 blend modes.
by Henri Verbeet 03 Feb '17

03 Feb '17

On 2 February 2017 at 19:29, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index 4b0ea06..0b801eb 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -400,6 +400,10 @@ enum wined3d_blend > WINED3D_BLEND_BOTHINVSRCALPHA = 13, > WINED3D_BLEND_BLENDFACTOR = 14, > WINED3D_BLEND_INVBLENDFACTOR = 15, > + WINED3D_BLEND_SRCCOLOR2 = 16, > + WINED3D_BLEND_INVSRCCOLOR2 = 17, > + WINED3D_BLEND_SRCALPHA2 = 18, > + WINED3D_BLEND_INVSRCALPHA2 = 19, > }; > What is this naming based on? In d3d11 these are called "D3D11_BLEND_INV_SRC1_ALPHA", etc.

2 1