|
From: Christoph S. <chr...@gm...> - 2012-08-11 05:34:52
|
Hi all,
I think the 3.8.0 release is a good occasion to give you an update on
the Valgrind for Windows development effort.
Since its inception last November, significant progress has been made.
But it is still a long way to go. So I'm calling again for any
interested developers to join the project.
The Valgrind for Windows code is now in synch with the 3.8.0 release.
Valgrind including all tools (except the two pthread error detectors),
as well as many test programs, build on Windows in both 32 and 64 bit
versions.
Simple applications can be run, compiled with MSVC or GCC, even GUI ones
("MessageBox"). Memory errors (buffer overruns, uninitialized memory,
memory leaks) are detected for 32 bit apps. The instrumentation, system
calls -including callbacks from system calls-, function redirection,
work in principle.
The biggest issues right now are stability and making progress in the
following areas:
1. debug information parsing, especially PDB, especially 64 bit
2. stack walking, both 32 and 64 bit
3. function redirection on 64 bit (32 bit seems to work)
Bugs such as Valgrind crashing because it might not properly read PDB
symbol information impede further progress (see
http://sourceforge.net/p/valgrind4win/tickets/17/)
There are other items on the list, please see the project homepage on
SourceForge: http://sourceforge.net/projects/valgrind4win/
Thanks for your interest, and thank you Julian and the other developers
for another great Valgrind release.
Chris
|
|
From: Julian S. <js...@ac...> - 2012-08-13 22:04:58
|
Hi Christoph,
Thanks for the update. It's great to hear this is being worked on.
> Simple applications can be run, compiled with MSVC or GCC, even GUI ones
> ("MessageBox"). Memory errors (buffer overruns, uninitialized memory,
> memory leaks) are detected for 32 bit apps. The instrumentation, system
> calls -including callbacks from system calls-, function redirection,
> work in principle.
>
> The biggest issues right now are stability and making progress in the
> following areas:
> 1. debug information parsing, especially PDB, especially 64 bit
> 2. stack walking, both 32 and 64 bit
> 3. function redirection on 64 bit (32 bit seems to work)
How well does it run GUI apps with --tool=none? I ask because 'none'
does not require any debuginfor reading to work, and so it is a good test
for how well your basic control-flow, memory management, etc, stuff works.
What are the problems with stack walking?
J
|
|
From: Christoph S. <chr...@gm...> - 2012-08-14 17:07:08
|
On 13/08/2012 2:54 PM, Julian Seward wrote:
>
> Hi Christoph,
>
> Thanks for the update. It's great to hear this is being worked on.
Hi Julian, nice to hear from you. I've been working on this project for
about a year now, and I am 100% sure that there can be a working
Valgrind for Windows one day. There are no unsolvable problems, it's
only a matter of effort. However my time is limited so the reason for
posting is to raise awareness about this project and hopefully attract
more developers.
>> Simple applications can be run, compiled with MSVC or GCC, even GUI ones
>> ("MessageBox"). Memory errors (buffer overruns, uninitialized memory,
>> memory leaks) are detected for 32 bit apps. The instrumentation, system
>> calls -including callbacks from system calls-, function redirection,
>> work in principle.
>>
>> The biggest issues right now are stability and making progress in the
>> following areas:
>> 1. debug information parsing, especially PDB, especially 64 bit
>> 2. stack walking, both 32 and 64 bit
>> 3. function redirection on 64 bit (32 bit seems to work)
>
> How well does it run GUI apps with --tool=none? I ask because 'none'
> does not require any debuginfor reading to work, and so it is a good test
> for how well your basic control-flow, memory management, etc, stuff works.
--tool=none works much better than --tool=memcheck. I basically test
with a simple "MessageBox" test program. I got the box pop up on Win32
and Win64 but not under Wow64. I can drag the box around and close it by
clicking the button.
I also tried to run Windows calculator. On Win32, the calculator
displays and I can open the menu bar. However, if I click any menu item
or button, the program stops abruptly.
Win64 calculator stopped because of a misaligned memory access before
displaying its window.
I have not looked into those issues as my focus is on non-GUI applications.
>
> What are the problems with stack walking?
Basically incomplete call stacks (displaying only one frame) or
incorrect location information. I filed several tickets on V4Ws tracker
describing the issues in detail.
The current implementation uses dbghelp's StackWalk function, however I
would prefer a solution that does not rely on this DLL but rather uses
its own implementation, like Linux.
Chris
|
|
From: Julian S. <js...@ac...> - 2012-08-13 22:22:21
|
(off-list) Hi. It is indeed great to see this move forward. I hope you can get it working well. Personally I would like to be able to run Windows builds of Firefox on it, and LibreOffice too, one day. I can't offer much Windows-specific help since I know zero about Windows internals. I can help with V specific questions, obviously .. so if you have any, please mail me (or, better, the V developers list and cc me). Also, please feel free to connect to #valgrind-dev at freenode.net. It is quite quiet during the day (CEST) but often there is some talk in the evenings. There are not many people in the channel, but most of the current V developers visit there at least once a day, so you should be there too. > Since its inception last November, significant progress has been made. > But it is still a long way to go. So I'm calling again for any > interested developers to join the project. Having ported V to some strange platforms over the years, I would say that some of the problems you are trying to solve (PDB reading, etc) are so specialised that it is likely you are already "the" expert on them. So it is relatively unlikely you will get much help, not because people are unhelpful but because it requires such specialised knowledge. I have seen this many times, eg, there are zero current maintainers for some parts of the MacOS port, because only one person ever understood it completely, and that person is not currently active. So .. it might be more successful for you to concentrate on the really difficult bits of the problem (eg, PDB reading, Windows syscalls/exceptions, etc) and try to get other people to try to do the more accessible parts, particularly testing, checking, feedback etc. Just my 2 euro-cents .. I would be interested at least to try it out. Another thing is .. maybe concentrate on just one variant (eg, 32-bit on some specific version of windows) and get that to work well. For one thing, having one variant that works well will pull more people in (since they can actually use it for real work) and it is encouraging, at a personal level. That is how all the other ports have developed, historically. I looked at the web site briefly. Is it possible to make a summary page describing (1) what combination of things (Windows versions, MSVC versions, etc) work best, and (2) giving simple instructions on how to check out and build? That would be useful, I think. J |