Valgrinding large win32 app worked!

[Eric Pouech]

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+

-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)