|
From: Julian S. <js...@ac...> - 2005-07-27 20:17:50
|
Greetings. Valgrind-3.0.0 Release Candidate 1 is available from http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 (md5sum == c3dc8089bebe7aba0822667b7850451e) This is our first attempt at what we believe to be a release-quality snapshot of the Valgrind-3.0 line. If all goes well, we hope to release a final 3.0 in about a week's time. This is the first Valgrind to support both x86-linux and amd64-linux. Support for ppc32-linux is also integrated but does not yet work well enough to be useful. Please download and test this release candidate, and let us know of any problems you encounter. This tarball is known to build and work on the following platforms: amd64 running SuSE 9.2 x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 ppc32 running Yellow Dog 4.0.1 (subject to caveats above) The attached release notes detail what is new in 3.0. Many thanks to all those who contributed to Valgrind's development. This RC represents a great deal of time, energy and effort on the part of many people. The Valgrind Developers --------------------------------------------------------------------- Release 3.0.0 ([[TODO: add release date]]) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user-visible change is that Valgrind now supports architectures other than x86. The new architectures it supports are AMD64 and PPC32, and the infrastructure is present for other architectures to be added later. The AMD64 support works well, but has some shortcomings: - It generally won't be as solid as the x86 version. For example, support for more obscure instructions and system calls may be missing. We will fix these as they arise. - Address space may be limited; see the point about position-independent executables below. - If Valgrind is built on an AMD64 machine, it will only run 64-bit executables. If you want to run 32-bit x86 executables under Valgrind on an AMD64, you will need to build Valgrind on an x86 machine and copy it to the AMD64 machine. And it probably won't work if you do something tricky like exec'ing a 32-bit program from a 64-bit program while using --trace-children=yes. We hope to improve this situation in the future. The PPC32 support is very basic. It may not work reliably even for small programs, but it's a start. Many thanks to Paul Mackerras for his great work that enabled this support. We are working to make PPC32 usable as soon as possible. Other user-visible changes: - No longer building Valgrind as a position-independent executable (PIE) by default, as it caused too many problems. Without PIE enabled, AMD64 programs will only be able to access 2GB of address space. We will fix this eventually, but not for the moment. Use --enable-pie at configure-time to turn this on. - Support for programs that use stack-switching has been improved. Use the --max-stackframe flag for simple cases, and the VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and VALGRIND_STACK_CHANGE client requests for trickier cases. - Support for programs that use self-modifying code has been improved, in particular programs that put temporary code fragments on the stack. This helps for C programs compiled with GCC that use nested functions, and also Ada programs. This is controlled with the --smc-check flag, although the default setting should work in most cases. - Output can now be printed in XML format. This should make it easier for tools such as GUI front-ends and automated error-processing schemes to use Valgrind output as input. The --xml flag controls this. As part of this change, ELF directory information is read from executables, so absolute source file paths are available if needed. [[TODO: describe the related CLOs added (eg. --log-file-qualifier)]] - Programs that allocate many heap blocks may run faster, due to improvements in certain data structures. - Addrcheck is currently not working. We hope to get it working again soon. Helgrind is still not working, as was the case for the 2.4.0 release. - The JITter has been completely rewritten, and is now in a separate library, called Vex. This enabled a lot of the user-visible changes, such as new architecture support. The new JIT unfortunately translates more slowly than the old one, so programs may take longer to start. We believe the code quality is produces is about the same, so once started, programs should run at about the same speed. Feedback about this would be useful. On the plus side, Vex and hence Memcheck tracks value flow properly through floating point and vector registers, something the 2.X line could not do. That means that Memcheck is much more likely to be usably accurate on vectorised code. - There is a subtle change to the way exiting of threaded programs is handled. In 3.0, Valgrind's final diagnostic output (leak check, etc) is not printed until the last thread exits. If the last thread to exit was not the original thread which started the program, any other process wait()-ing on this one to exit may conclude it has finished before the diagnostic output is printed. This may not be what you expect. 2.X had a different scheme which avoided this problem, but caused deadlocks under obscure circumstances, so we are trying something different for 3.0. - Small changes in control log file naming which make it easier to use valgrind for debugging MPI-based programs. - As part of adding AMD64 support, DWARF2 CFI-based stack unwinding support was added. In principle this means Valgrind can produce meaningful backtraces on x86 code compiled with -fomit-frame-pointer providing you also compile your code with -fasynchronous-unwind-tables. - [[TODO: add more here]] Changes that are not user-visible: - The code has been massively overhauled in order to modularise it. As a result we hope it is easier to navigate and understand. - Lots of code has been rewritten. - [[TODO: add more here]] BUGS FIXED [[TODO: add the full list here (once the RCs are out of the way?)]] (3.0RC1: 27 July 05, vex r1303, valgrind r4283). |