- Wine-devel - list.winehq.org

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 10:43 AM 05/06/2001 +0200, you wrote: >> This calls fails because glibc detects that the value at (esp+28) >> is different of 0 - the real system call is never done, with your >> test app and Wine. > >Well, note that the second version is only pushing a 32bit offset, so >mmap64 accesses random stack space! Yes :-/ <snip> >Yes, check the sys/mman.h header, it should have __off64_t as argument >to the mmap ... asm("mmap64") not __off_t. Yes, it is __off_t and that is the problem; but how this header has come to be in this state is part of what I don't understand. It's marked as part of the glibc, but there is nothing like it in the glibc source that I used to compile. The mman.h in my glibc source is much shorter and the declaration of mmap64 seems correct. I guess that the file in my /usr/include/sys/mman.h is a generated file. I don't even want to count the number of 'mman.h' files on my system :-/ >So I think I can use this test program as check for mmap64 brokeness... Btw, the reference on large files http://www.suse.de/~aj/linux_lfs.html says that locking will never be supported on 64 bits files with glibc 2.1.3 so I don't see why it's necessary to support this case. Gerard

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

> On Tue, 5 Jun 2001 David.Goodenough(a)dga.co.uk wrote: > > but has anyone thought of running these against Wine? > > I'm not sure if it'd do that much good. They're currently working on > checking the XFree86 tree (see the Xpert mailing list archives on > www.XFree86.org if you want), without a lot of big results > yet. From what > I gather, this tool has very limited and context-dependent > intelligence, Perhaps. But see below. > and is not conceptually very different from what a glorified > version of > Patrik's tools/winapi_check script might be, if given enough people > working on it. Not quite. winapi_check is 1. Specifically written for Wine 2. A syntax analyzer 3. Mostly ad hoc. The Stanford checker on the other hand is 1. Generalized for all C/C++ applications 2. A semantic analyzer 3. Formalized with a script language The way I choose when designing winapi_check was the one of the easiest ways and the way they choose is one of the hardest. So just calling it is glorified winapi_check gives the Stanford people too little credit. Anyway the way Stanford choose is really _very_ hard so what I fear is that they had to make some limiting decisions that makes their tool much less useful. That said regardless of how good the Stanford checker really will be I'm pretty there will be a lot of things that will be _much_ easier checked by writting a script for the Stanford checker than by extending winapi_check, because they have fundamentally different design philosofies. However don't underestimate winapi_check either. There is a lot of things that can quite easilt be checked by adding some clever perl pattern, if:s and a little state. Syntax level matching is not that bad just a little more crude. If somebody have something that he want to be automatically checked, please post it on the list and I will see what I can do.

1 0

Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

On the kernel list and in Alan Cox's patches for the kernel there are a lot of references to some logic checking tools being generated by Stanford. I do not know if these are generally available but has anyone thought of running these against Wine?

2 1

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

> Maybe we have to ask them to check our code, rather than the other way > around? I think it far to much to ask. As Eric said, while it is AFAIK highly configurable with specific scripts, for each kind of check it is currently seems to be very much focused on the Linux kernel. I also believe, like Eric, that it is currently very buggy and that even if they have a powerful enough scripting language to be usable for Wine it will probably need some serious debugging to make the scripts we need to actually work in practise not only in theory. No, as I said, I think it is to much to ask. We will have to wait until they release it whenever that will be.

1 0

Re:Stanford Checker
by Eric Pouech 05 Jun '01

05 Jun '01

last time I checked (a month ago), the tool wasn't freely available (nor finished), so nothing can be done for now when the tool is finished (<put here your date estimation>), one could be able to configure the tool for use in Wine (read: write the scripts for the things we want to check, like windows locks...) but, the tool is (as of today) configured for Linux, and check can only be done agains the Linux tree (AFAIU, they check for specific constructs like getting a spin lock, enabling / disabling IRQ... so highly dependent on Linux source...) however, I don't know (yet) the power of the script language they use for configuring, and whether it could be used for Wine... you'll have to wait until the tool is released... (I suspect, the tool is still buggy *AND* still requires lots of processing by hand - you get a 100 warnings from where only a few are real issues). A+ > On the kernel list and in Alan Cox's patches for the kernel there are a lot > of references to some logic checking tools being generated by Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

RE: Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

Maybe we have to ask them to check our code, rather than the other way around? Patrik Stridvall <ps(a)leissner.se> on 05-06-2001 12:31:25 PM To: David Goodenough/DGA/GB cc: wine-devel(a)winehq.com Subject: RE: Stanford Checker [Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

[Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

CVS compilation problem: XvSelectNotify
by Heiko Nardmann 05 Jun '01

05 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just compiled CVS wine using ./configure --prefix=/opt/wine-20010605 --enable-dll --with-x and get the following error message starting Word: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /opt/wine-20010510/lib/libwine_tsx11.so: undefined symbol: XvSelectPortNotify Could not load graphics driver 'x11drv' - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7HJ2Opm53PRScYygRAkZsAKCXRyt3ncR7sFRNatc7/6Bls3+eywCg9sO5 7oombEYBU9llG4o8Gp7LeyA= =a8Qa -----END PGP SIGNATURE-----

1 0

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 07:20 AM 05/06/2001 +0200, you wrote: >Not really, as Alexandre said. > >Could you please test the attached small test program? It fails (of course). Here is the call with my working computer (glibc2.2, linux 2.4) 0x8048668 <main+72>: call 0x8048464 <write> 0x804866d <main+77>: add $0xc,%esp 0x8048670 <main+80>: push $0x0 0x8048672 <main+82>: push $0x0 0x8048674 <main+84>: push %ebx 0x8048675 <main+85>: push $0x1 0x8048677 <main+87>: push $0x3 0x8048679 <main+89>: push $0x4 0x804867b <main+91>: push $0x0 0x804867d <main+93>: call 0x80484a4 <mmap64>p For the failing one : 0x80486c8 <main+72>: call 0x80484dc <write> 0x80486cd <main+77>: addl $0x20,%esp 0x80486d0 <main+80>: addl $0xfffffff8,%esp 0x80486d3 <main+83>: pushl $0x0 0x80486d5 <main+85>: pushl %ebx 0x80486d6 <main+86>: pushl $0x1 0x80486d8 <main+88>: pushl $0x3 0x80486da <main+90>: pushl $0x4 0x80486dc <main+92>: pushl $0x0 0x80486de <main+94>: call 0x804851c <mmap64> This calls fails because glibc detects that the value at (esp+28) is different of 0 - the real system call is never done, with your test app and Wine. In the glibc 2.1.3 source, this test is not explained; in the 2.2.2 source, there is a comment saying that the offset is 'too large'. I understand that the app is calling mmap64 on an operating system that is not supporting it (it's perfectly correct in this case, the failing box having 2.2.5 kernel), and glibc tests if the call can be mapped to standard mmap. I think that the problem is in the compilation; pushing only 6 dwords on the stack to call mmap64 is wrong. I have not yet figured out why, though (I have never been any good with C header problems) Gerard

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 08:12 AM 03/06/2001 +0200, you wrote: >> After applying your patch to current cvs, rm config.cache, ./configure, >> make depend && make Wine crashes as before. > >You need to run 'autoheader -l include' if any change to acconfig.h >is submitted. Thanks, it worked. Problem solved IMO. Gerard

1 0