January 2014 - Wine-Devel - list.winehq.org

Build fixes for wine-1.6.1 (FreeType2)

by David Naylor

Dear Wine-developers, On behalf of Gerald Pfeifer and the FreeBSD/Wine team I would like to report that wine-1.6.1 does not build against recent versions of FreeType2. This has been fixed in master in commit 67f9b6e3c5d2397446d39ab454f691c1ee46d2c0 by Alexandre Julliard. We would like to request this commit be back-ported to the stable branch. Regards, David P.S. I'm not on the mailing list, please CC me in related correspondence, thanks.

Jan. 3, 2014

Re: advapi32/tests: Use BOOL type where appropriate

by Dmitry Timoshkov

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > diff --git a/dlls/advapi32/tests/security.c b/dlls/advapi32/tests/security.c > index 9f1e611..232a729 100644 > --- a/dlls/advapi32/tests/security.c > +++ b/dlls/advapi32/tests/security.c > @@ -4526,13 +4526,14 @@ static void test_mutex_security(HANDLE token) > STANDARD_RIGHTS_ALL | MUTEX_ALL_ACCESS }; > static const struct > { > - int todo, generic, mapped; > + BOOL todo; > + int generic, mapped; > } map[] = > { > - { 1, GENERIC_READ, STANDARD_RIGHTS_READ | MUTANT_QUERY_STATE }, > - { 0, GENERIC_WRITE, STANDARD_RIGHTS_WRITE }, > - { 0, GENERIC_EXECUTE, STANDARD_RIGHTS_EXECUTE | SYNCHRONIZE }, > - { 0, GENERIC_ALL, STANDARD_RIGHTS_ALL | MUTANT_QUERY_STATE } > + { TRUE, GENERIC_READ, STANDARD_RIGHTS_READ | MUTANT_QUERY_STATE }, > + { FALSE, GENERIC_WRITE, STANDARD_RIGHTS_WRITE }, > + { FALSE, GENERIC_EXECUTE, STANDARD_RIGHTS_EXECUTE | SYNCHRONIZE }, > + { FALSE, GENERIC_ALL, STANDARD_RIGHTS_ALL | MUTANT_QUERY_STATE } > }; Please don't touch these tests, 'int' is intentionally used here, and 'BOOL' buys you nothing. It's better to actually fix the source of these todos and remove them altogether. -- Dmitry.

Jan. 3, 2014

Re: ddraw/tests: Use BOOL type where appropriate

by Marvin

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://newtestbot.winehq.org/JobDetails.pl?Key=3950 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag

Jan. 3, 2014

Re: [PATCH] ntdll: Improve handling of THUMB_MOV32 relocations

by André Hentschel

Am 02.01.2014 21:57, schrieb Martin Storsjö: > On Thu, 2 Jan 2014, André Hentschel wrote: > >> Am 02.01.2014 17:01, schrieb Martin Storsjo: >>> Since the delta variable actually is signed, the delta > 0xffff >>> condition could be false even if the high part of the delta >>> was nonzero, ending up with not updating the high half of the >>> relocation at all. >>> >>> Additionally, carry any overflow from the low word into the >>> high word delta. >> >> >> Hi, >> Do you have an App that triggers that? > > I've got a 5 MB .exe that triggers this occasionally. If I disable ASLR in the kernel, it doesn't trigger. I guess the bigger the image, the larger the risk that ASLR will force the exe to be relocated, triggering the issue. > > Conversely, if I change map_image to not try to load the image at the base address (as if it would have failed to load at that address due to ASLR), this triggers every time even with a small hello world .exe. > >> So you mean the case when the sign bit is used, e.g. 10101010b... Then the delta is negative, but is everything set correctly in the instruction? > > Yes, the calculation seem to work just fine with my patch applied. With the 5 MB .exe, the relocation that is done on startup was: > > trace:module:map_image relocating from 0x400000-0xe6e000 to 0xb58a0000-0xb630e000 > > So the delta really isn't negative per se, but it's too large to represent with a 32 bit signed integer. > > > So to reproduce easily, apply this diff to your tree, then try to execute http://albin.abo.fi/~mstorsjo/helloworld-arm.exe (a plain hello world exe compiled with msvc 2012 for winrt). At least here, it tries to relocate the .exe from 0x400000-0x410000 to 0xb6200000-0xb6210000. > > index e93ce2e..a6ffe38 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -1077,9 +1077,6 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > > server_enter_uninterrupted_section( &csVirtual, &sigset ); > > - if (base >= (char *)address_space_start) /* make sure the DOS area remains free */ > - status = map_view( &view, base, total_size, mask, FALSE, > - VPROT_COMMITTED | VPROT_READ | VPROT_EXEC | VPROT_WRITECOPY | VPROT_IMAGE ); > > if (status != STATUS_SUCCESS) > status = map_view( &view, NULL, total_size, mask, FALSE, > > > >>> --- >>> dlls/ntdll/loader.c | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c >>> index e0907e7..1f13424 100644 >>> --- a/dlls/ntdll/loader.c >>> +++ b/dlls/ntdll/loader.c >>> @@ -2230,19 +2230,19 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count >>> DWORD inst = *(INT_PTR *)((char *)page + offset); >>> DWORD imm16 = ((inst << 1) & 0x0800) + ((inst << 12) & 0xf000) + >>> ((inst >> 20) & 0x0700) + ((inst >> 16) & 0x00ff); >>> + int hi_delta; >> >> Why you're using int here? DWORD looks much better for this. > > No particular reason, DWORD should work just fine as well, it seems. I can send a new patch with that changed if you're ok with the rest of it - just let me know. You've done your homework :) so yeah, DWORD would be better imho.

Jan. 2, 2014

Re: [PATCH] ntdll: Improve handling of THUMB_MOV32 relocations

by Martin Storsjö

On Thu, 2 Jan 2014, André Hentschel wrote: > Am 02.01.2014 17:01, schrieb Martin Storsjo: >> Since the delta variable actually is signed, the delta > 0xffff >> condition could be false even if the high part of the delta >> was nonzero, ending up with not updating the high half of the >> relocation at all. >> >> Additionally, carry any overflow from the low word into the >> high word delta. > > > Hi, > Do you have an App that triggers that? I've got a 5 MB .exe that triggers this occasionally. If I disable ASLR in the kernel, it doesn't trigger. I guess the bigger the image, the larger the risk that ASLR will force the exe to be relocated, triggering the issue. Conversely, if I change map_image to not try to load the image at the base address (as if it would have failed to load at that address due to ASLR), this triggers every time even with a small hello world .exe. > So you mean the case when the sign bit is used, e.g. 10101010b... Then the delta is negative, but is everything set correctly in the instruction? Yes, the calculation seem to work just fine with my patch applied. With the 5 MB .exe, the relocation that is done on startup was: trace:module:map_image relocating from 0x400000-0xe6e000 to 0xb58a0000-0xb630e000 So the delta really isn't negative per se, but it's too large to represent with a 32 bit signed integer. So to reproduce easily, apply this diff to your tree, then try to execute http://albin.abo.fi/~mstorsjo/helloworld-arm.exe (a plain hello world exe compiled with msvc 2012 for winrt). At least here, it tries to relocate the .exe from 0x400000-0x410000 to 0xb6200000-0xb6210000. index e93ce2e..a6ffe38 100644 --- a/dlls/ntdll/virtual.c +++ b/dlls/ntdll/virtual.c @@ -1077,9 +1077,6 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz server_enter_uninterrupted_section( &csVirtual, &sigset ); - if (base >= (char *)address_space_start) /* make sure the DOS area remains free */ - status = map_view( &view, base, total_size, mask, FALSE, - VPROT_COMMITTED | VPROT_READ | VPROT_EXEC | VPROT_WRITECOPY | VPROT_IMAGE ); if (status != STATUS_SUCCESS) status = map_view( &view, NULL, total_size, mask, FALSE, >> --- >> dlls/ntdll/loader.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c >> index e0907e7..1f13424 100644 >> --- a/dlls/ntdll/loader.c >> +++ b/dlls/ntdll/loader.c >> @@ -2230,19 +2230,19 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count >> DWORD inst = *(INT_PTR *)((char *)page + offset); >> DWORD imm16 = ((inst << 1) & 0x0800) + ((inst << 12) & 0xf000) + >> ((inst >> 20) & 0x0700) + ((inst >> 16) & 0x00ff); >> + int hi_delta; > > Why you're using int here? DWORD looks much better for this. No particular reason, DWORD should work just fine as well, it seems. I can send a new patch with that changed if you're ok with the rest of it - just let me know. // Martin

Jan. 2, 2014

Re: [PATCH] ntdll: Improve handling of THUMB_MOV32 relocations

by André Hentschel

Am 02.01.2014 17:01, schrieb Martin Storsjo: > Since the delta variable actually is signed, the delta > 0xffff > condition could be false even if the high part of the delta > was nonzero, ending up with not updating the high half of the > relocation at all. > > Additionally, carry any overflow from the low word into the > high word delta. Hi, Do you have an App that triggers that? So you mean the case when the sign bit is used, e.g. 10101010b... Then the delta is negative, but is everything set correctly in the instruction? > --- > dlls/ntdll/loader.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index e0907e7..1f13424 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2230,19 +2230,19 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count > DWORD inst = *(INT_PTR *)((char *)page + offset); > DWORD imm16 = ((inst << 1) & 0x0800) + ((inst << 12) & 0xf000) + > ((inst >> 20) & 0x0700) + ((inst >> 16) & 0x00ff); > + int hi_delta; Why you're using int here? DWORD looks much better for this.

Jan. 2, 2014

Re: How to bisect the 1.6.x series of commits

by André Hentschel

Am 02.01.2014 20:01, schrieb Alan W. Irwin: > I have bisected Wine regressions several times in the last year > following the cookbook in http://wiki.winehq.org/RegressionTesting. > Those bisections were for the principal branch (or whatever you call > it) of development. How do you do similar bisections for the branch of > development from 1.6 to 1.6.1? I need the name of that branch of > development and how you specify it to the bisect process. Sorry for > the git newbie question, but following the above cookbook has been > essentially my only git experience to date. > > The reason I am asking about bisecting from 1.6 to 1.6.1 is I have > recently found some fairly strong evidence that there is an important > regression in behavior between 1.6-rc4 and 1.6.1. I have used Wine > 1.6-rc4 with a lot of success as a test platform for MinGW/MSYS PLplot > builds and tests, but when I recently tried 1.6.1, my usual parallel > tests of PLplot software failed with an error indicating plot devices > (small dll's) cannot be dynamically loaded by the PLplot principal > library for that version of Wine. (The problem disappears if I do the > tests sequentially for 1.6.1, but I obviously want to avoid that > method of testing because it doubles the test time for my two-cpu PC.) > git checkout origin/stable git branch stable git checkout stable now you can move between branches with git checkout you can see them with git branch

Jan. 2, 2014

Re: How to bisect the 1.6.x series of commits

by Ken Thomases

On Jan 2, 2014, at 1:01 PM, Alan W. Irwin wrote: > I have bisected Wine regressions several times in the last year > following the cookbook in http://wiki.winehq.org/RegressionTesting. > Those bisections were for the principal branch (or whatever you call > it) of development. How do you do similar bisections for the branch of > development from 1.6 to 1.6.1? I need the name of that branch of > development and how you specify it to the bisect process. Sorry for > the git newbie question, but following the above cookbook has been > essentially my only git experience to date. > > The reason I am asking about bisecting from 1.6 to 1.6.1 is I have > recently found some fairly strong evidence that there is an important > regression in behavior between 1.6-rc4 and 1.6.1. You can simply do "git bisect good wine-1.6-rc4" and "git bisect bad wine-1.6.1" or the equivalent. Git will traverse the commits between them. It doesn't need a branch name or anything like that. Cheers, Ken

Jan. 2, 2014

How to bisect the 1.6.x series of commits

by Alan W. Irwin

I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date. The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1. I have used Wine 1.6-rc4 with a lot of success as a test platform for MinGW/MSYS PLplot builds and tests, but when I recently tried 1.6.1, my usual parallel tests of PLplot software failed with an error indicating plot devices (small dll's) cannot be dynamically loaded by the PLplot principal library for that version of Wine. (The problem disappears if I do the tests sequentially for 1.6.1, but I obviously want to avoid that method of testing because it doubles the test time for my two-cpu PC.) The tests of 1.6-rc4 and 1.6.1 were quite similar but not absolutely identical so I do have to confirm the regression in behaviour for 1.6.1 with absolutely identical tests. But assuming I can do that, then I still have to discover if the problem occurred for 1.6. If so, the bisection needs to be an ordinary principal branch one that I am already familiar with between 1.6-rc4 and 1.6, but if not it needs to follow the 1.6.x development branch between 1.6 an 1.6.1. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Jan. 2, 2014

Re: msvcp80: Fix ostreambuf_iterator<char> structure definition

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcp90/ios.c | 88 > +++++++++++++++++++++++++++++++++++++------------- > dlls/msvcp90/msvcp90.h | 6 ++++ > 2 files changed, 72 insertions(+), 22 deletions(-) It breaks the Mingw build: locale.o:locale.c:(.text+0x94c): undefined reference to `_num_put_char_do_put_long(a)28' locale.o:locale.c:(.text+0x954): undefined reference to `_num_put_char_put_long(a)28' locale.o:locale.c:(.text+0x95c): undefined reference to `_num_put_char_do_put_ulong(a)28' locale.o:locale.c:(.text+0x964): undefined reference to `_num_put_char_put_ulong(a)28' locale.o:locale.c:(.text+0x96c): undefined reference to `_num_put_char_do_put_double(a)32' locale.o:locale.c:(.text+0x974): undefined reference to `_num_put_char_put_double(a)32' locale.o:locale.c:(.text+0x97c): undefined reference to `_num_put_char_put_ldouble(a)32' locale.o:locale.c:(.text+0x984): undefined reference to `_num_put_char_do_put_ptr(a)28' locale.o:locale.c:(.text+0x98c): undefined reference to `_num_put_char_put_ptr(a)28' locale.o:locale.c:(.text+0x994): undefined reference to `_num_put_char_do_put_int64(a)32' locale.o:locale.c:(.text+0x99c): undefined reference to `_num_put_char_put_int64(a)32' locale.o:locale.c:(.text+0x9a4): undefined reference to `_num_put_char_do_put_uint64(a)32' locale.o:locale.c:(.text+0x9ac): undefined reference to `_num_put_char_put_uint64(a)32' locale.o:locale.c:(.text+0x9b4): undefined reference to `_num_put_char_do_put_bool(a)28' locale.o:locale.c:(.text+0x9bc): undefined reference to `_num_put_char_put_bool(a)28' locale.o:locale.c:(.text+0xa0c): undefined reference to `_num_put_wchar_do_put_long(a)28' locale.o:locale.c:(.text+0xa14): undefined reference to `_num_put_short_do_put_long(a)28' locale.o:locale.c:(.text+0xa1c): undefined reference to `_num_put_wchar_put_long(a)28' locale.o:locale.c:(.text+0xa24): undefined reference to `_num_put_wchar_do_put_ulong(a)28' locale.o:locale.c:(.text+0xa2c): undefined reference to `_num_put_short_do_put_ulong(a)28' locale.o:locale.c:(.text+0xa34): undefined reference to `_num_put_wchar_put_ulong(a)28' locale.o:locale.c:(.text+0xa3c): undefined reference to `_num_put_wchar_do_put_double(a)32' locale.o:locale.c:(.text+0xa44): undefined reference to `_num_put_short_do_put_double(a)32' locale.o:locale.c:(.text+0xa4c): undefined reference to `_num_put_wchar_put_double(a)32' locale.o:locale.c:(.text+0xa54): undefined reference to `_num_put_wchar_put_ldouble(a)32' locale.o:locale.c:(.text+0xa5c): undefined reference to `_num_put_wchar_do_put_ptr(a)28' locale.o:locale.c:(.text+0xa64): undefined reference to `_num_put_short_do_put_ptr(a)28' locale.o:locale.c:(.text+0xa6c): undefined reference to `_num_put_wchar_put_ptr(a)28' locale.o:locale.c:(.text+0xa74): undefined reference to `_num_put_wchar_do_put_int64(a)32' locale.o:locale.c:(.text+0xa7c): undefined reference to `_num_put_short_do_put_int64(a)32' locale.o:locale.c:(.text+0xa84): undefined reference to `_num_put_wchar_put_int64(a)32' locale.o:locale.c:(.text+0xa8c): undefined reference to `_num_put_wchar_do_put_uint64(a)32' locale.o:locale.c:(.text+0xa94): undefined reference to `_num_put_short_do_put_uint64(a)32' locale.o:locale.c:(.text+0xa9c): undefined reference to `_num_put_wchar_put_uint64(a)32' locale.o:locale.c:(.text+0xaa4): undefined reference to `_num_put_wchar_do_put_bool(a)28' locale.o:locale.c:(.text+0xaac): undefined reference to `_num_put_short_do_put_bool(a)28' locale.o:locale.c:(.text+0xab4): undefined reference to `_num_put_wchar_put_bool(a)28' locale.o:locale.c:(.text+0xaec): undefined reference to `_time_put_char_do_put(a)36' locale.o:locale.c:(.text+0xaf4): undefined reference to `_time_put_char_put(a)36' locale.o:locale.c:(.text+0xafc): undefined reference to `_time_put_char_put_format(a)36' locale.o:locale.c:(.text+0xb5c): undefined reference to `_time_put_wchar_do_put(a)36' locale.o:locale.c:(.text+0xb64): undefined reference to `_time_put_wchar_put(a)36' locale.o:locale.c:(.text+0xb6c): undefined reference to `_time_put_wchar_put_format(a)36' collect2: ld returned 1 exit status -- Alexandre Julliard julliard(a)winehq.org

Jan. 2, 2014