At 19:45 01/04/03 -0600, Eric Pouech pouech-eric@wanadoo.fr wrote:
Adam Gundy wrote:
a new version of the valgrind patch has been uploaded to sourceforge - the only change is a small fix to the signal handling which should prevent "signal handler frame" uninitialized errors.
http://sourceforge.net/tracker/index.php?func=detail&aid=710006&grou...
comments? bug reports? success stories?
did test it yet.
As a global note, I think it would be appreciated breaking the patch in smaller bits... it makes it easier to track/follow what happens. For example, I don't see any reason for including the msvcrtd patches into this patch
the reason msvcrtd is there is that you need to use it for valgrind to do any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c) is required to tell valgrind that freshly allocated blocks are uninitialized, and the freed blocks are now invalid.
If you build a debug executable using MSVC you have to use MSVCRTD.DLL, hence the new spec file for msvcrtd.dll.so
I think that Alexandre is currently integrating (bit per bit) your changes into wine. look for the patch about zeroing the request zones (which is another implementation of your structure packing), as well as local availability of the thread PID
haven't seen these yet
on a more minor side of things, I would keep the VALGRIND prefix in heap.c
not sure what you mean here, but the heap.c stuff appears to have been committed (slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD stuff as well though!
last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind)
maybe, this was just a hack to make it easier to use "in tree". not sure people would want a "--valgrind" switch in a (presumably) production winelib piece of software - it would show the world all your bugs ;-)
how are your patches doing on the "other side" (I mean valgrind's) ?
just starting to make progress into CVS commits - there appear to be several other patches which overlap with mine, so there will probably be some ordering and refactoring required...
Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.