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. - Dan
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+
On Jan 16, 2008 12:25 PM, Eric Pouech eric.pouech@orange.fr wrote:
btw: the bug (11211) is rather strange. the crash occurs while loading dwarf information, not pdb. Does it occurs in every usage of winedbg ?
I'm not sure. It happens lots, not just on this app. I haven't looked into it at all. - Dan
On Jan 16, 2008 12:25 PM, Eric Pouech eric.pouech@orange.fr wrote:
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)
That's good to hear. I must have blinked :-)
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
Thanks for the tips. I don't suppose you'd have time to look at any of this? :-) - Dan
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
Thanks for the tips. I don't suppose you'd have time to look at any of this? :-)
- Dan
since you're asking, no ;-) A+
Eric Pouech wrote:
Dan Kegel a écrit :
... I can run Picasa for Windows under Wine under Valgrind.
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 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
Yes, a new VALGRIND_USER_REQUEST which announces the load/unload, supported by loadable shared libraries which generate symbols and addresses to be added/removed from the currently-running valgrind, is the way to go.
The only snag could be, does PE format allow a separate base address for each "segment", or are all segments fixed relative to each other, like the PT_LOAD in ET_DYN?
The only snag could be, does PE format allow a separate base address for each "segment", or are all segments fixed relative to each other, like the PT_LOAD in ET_DYN?
each segment is described as an offset to the module's base address, but the offset are fixed in the PE format (as well as in .pdb) anyhow, this information is present both in the PE header and the debug info
A+
-
Dan Kegel -
Dan Kegel -
Eric Pouech -
John Reiser