valgrind for WINE

[Eric Pouech]

> 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.
IMO you need msvcrd for running under wine a windows program compiled 
with both DEBUG turned on, and linking to MSVCRT
you don't need msvcrtd at all to run, say, a winelib program with 
valgrind enabled (I assume this comes from the fact you did most of the 
testing with a wine running a windows app which has been compiled with 
the DEBUG flag on)
anyway, that's pure semantic. I doesn't change the real benefit behind: 
being able to run wine under valgrind !!

>>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!
basically, partly what Alexandre did to your patch => keeping the code 
(and macros) which are valgrind related being prefixed with VALGRIND

>>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 ;-)
sure!!! that's why putting it in a file external to winewrapper might be 
a good solution too (lile the .winewrapper)

A+
-- 
Eric Pouech