Dan Kegel a écrit :
This script, http://kegel.com/wine/valgrind/valgrind-330-build.sh builds a copy of valgrind-3.3.0 with John Reiser's forward port of the Wine support patch. With that, I can run Picasa for Windows under Wine under Valgrind. It takes 40 seconds to start up on my 1.3GHz Athlon 64, which is right in line with Valgrind's legendary ~10x overhead.
It seemed to find lots of little problems, but since there were lots of numeric addresses without symbolic info in the valgrind log, it wasn't directly useful to the Picasa developers.
The next step, I suppose, is to find a way to make the valgrind log contain symbolic identifiers for the functions in the Windows app. I looked at that for a few minutes; here are some notes that might provide a starting point.
http://www.debuginfo.com/articles/gendebuginfo.html is the best overview I've seen so far on how to tell Visual C++ to generate debugging info; for most apps, the preferred debug info format will be .pdb.
http://www.debuginfo.com/articles/dbghelptypeinfo.html has an example win32 app that will dump all public symbols from a win32 app. It runs fine on Windows XP, and can dump symbols for Picasa (generating a 9MB text file). (I happen to have the .pdb file for Picasa handy since I are an honorary Picasa developer.) Sadly, that symbol dumper crashes on Wine, see http://bugs.winehq.org/show_bug.cgi?id=11211
Also, the unresolved error addresses in the valgrind trace were mostly in the 0x400000 - 0x420000 range, whereas the symbols dumped by that dumper app were all in the range 0x1000000 - 0x1080000... maybe the base load address is different between the two OS's. I haven't tried valgrinding a toy app yet, but that's probably the easiest way to figure out how to match the symbols up.
the hard part is not about understanding the .pdb format our winedump already does it !! and dbghelp supports coff and .pdb debug information (less tested than stabs and dwarf2 of course)
the hard part is to tell valgrind about information about modules it doesn't know of: - it doesn't know about the loading of the module (it's seen by vg as a simple mmap) - it doesn't know about the PE native debug information (whatever it is)
the simplest approach would be to somehow: - use the --db-attach option in vg to hook to a debugger on every error (one hurdle is that valgrind doesn't allow both trace-children and db-attach) - then use winedbg to get a backtrace (or similar info) from the running program (winedbg will be able to get to both .pdb and dwarf debug info)
the ultimate goal is rather to ask vg to support new messages about: - loading / unloading modules - having external .so files to understand more detailed information, and implement in them pdb and coff support
btw: the bug (11211) is rather strange. the crash occurs while loading dwarf information, not pdb. Does it occurs in every usage of winedbg ?
A+