|
From: Dirk M. <dm...@gm...> - 2005-07-21 00:52:36
|
Hi, I've looked into the valgrind-2.4 branch and de-digested the changes in it: BUGS FIXED: - fixed regression in stabs parsing introduced by fixing bug 90128 - major performance fix by Pete Moceyunas to improve malloc handling. - several smaller fixes to the code, as detected in a code analysis performed by Madhu Kurup using the "Prevent" Standford code checker. - VG_(atoll36) fixed. - fixed double free in reading ~/.valgrindrc - removed irrelevant linker version script that broke compilation with newer binutils. - 88678: fix debug info for file names containing spaces - 106713: preserve %esi accross calls to clone. - 103509, 106293, 104797, 101881: backported from 3.0 development - fix valgrind crash when no environment is given to an execve() call - disable PIE compilation by default, it just caused too many nonworking builds and accordingly many bugreports. - fix stabs debug info reading for FreePascal binaries New features: The macros VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and VALGRIND_STACK_CHANGE have been added. These can be used to inform valgrind about stack switches (if your application uses userland threading libraries). Thats not a big list, but its still something I think. So would it be okay with everyone if I prepare a tarball and prepare updates to the website? Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-07-21 17:01:45
|
On Thu, 21 Jul 2005, Dirk Mueller wrote: > BUGS FIXED: > > Standford code checker. s/Standford/Stanford/ > Thats not a big list, but its still something I think. So would it be okay > with everyone if I prepare a tarball and prepare updates to the website? Seems ok to me. The lack of response seems to indicate that no-one else has strong opinions either. I wonder if it's worth doing a release candidate, but if it's only bug fixes things should (in theory) work ok out of the box. N |