|
From: <sv...@va...> - 2005-08-27 17:29:55
|
Author: njn Date: 2005-08-27 18:29:51 +0100 (Sat, 27 Aug 2005) New Revision: 181 Log: whoops Added: trunk/info/release-notes-3.0.0.txt Removed: trunk/release-notes-3.0.0.txt Copied: trunk/info/release-notes-3.0.0.txt (from rev 180, trunk/release-n= otes-3.0.0.txt) Deleted: trunk/release-notes-3.0.0.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/release-notes-3.0.0.txt 2005-08-27 17:29:02 UTC (rev 180) +++ trunk/release-notes-3.0.0.txt 2005-08-27 17:29:51 UTC (rev 181) @@ -1,154 +0,0 @@ - -Release 3.0.0 (3 August 2005) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -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. - -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=3Dyes. 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: - -- Valgrind is no longer built by default as a position-independent - executable (PIE), as this 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. - =20 - 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 executa= bles, - so absolute source file paths are available if needed. - -- 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 translate= s - 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. The relevant - new flags are --log-file-exactly=3D and --log-file-qualifier=3D. - -- 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= . - -- The documentation build system has been completely redone. - The documentation masters are now in XML format, and from that - HTML, PostScript and PDF documentation is generated. As a result - the manual is now available in book form. Note that the - documentation in the source tarballs is pre-built, so you don't need - any XML processing tools to build Valgrind from a tarball. - -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. - -BUGS FIXED: - -110046 sz =3D=3D 4 assertion failed=20 -109810 vex amd64->IR: unhandled instruction bytes: 0xA3 0x4C 0x70 0xD7 -109802 Add a plausible_stack_size command-line parameter ? -109783 unhandled ioctl TIOCMGET (running hw detection tool discover)=20 -109780 unhandled ioctl BLKSSZGET (running fdisk -l /dev/hda) -109718 vex x86->IR: unhandled instruction: ffreep=20 -109429 AMD64 unhandled syscall: 127 (sigpending) -109401 false positive uninit in strchr from ld-linux.so.2 -109385 "stabs" parse failure=20 -109378 amd64: unhandled instruction REP NOP -109376 amd64: unhandled instruction LOOP Jb=20 -109363 AMD64 unhandled instruction bytes=20 -109362 AMD64 unhandled syscall: 24 (sched_yield) -109358 fork() won't work with valgrind-3.0 SVN -109332 amd64 unhandled instruction: ADC Ev, Gv -109314 Bogus memcheck report on amd64 -108883 Crash; vg_memory.c:905 (vgPlain_init_shadow_range): - Assertion `vgPlain_defined_init_shadow_page()' failed. -108349 mincore syscall parameter checked incorrectly=20 -108059 build infrastructure: small update -107524 epoll_ctl event parameter checked on EPOLL_CTL_DEL -107123 Vex dies with unhandled instructions: 0xD9 0x31 0xF 0xAE -106841 auxmap & openGL problems -106713 SDL_Init causes valgrind to exit -106352 setcontext and makecontext not handled correctly=20 -106293 addresses beyond initial client stack allocation=20 - not checked in VALGRIND_DO_LEAK_CHECK -106283 PIE client programs are loaded at address 0 -105831 Assertion `vgPlain_defined_init_shadow_page()' failed. -105039 long run-times probably due to memory manager=20 -104797 valgrind needs to be aware of BLKGETSIZE64 -103594 unhandled instruction: FICOM -103320 Valgrind 2.4.0 fails to compile with gcc 3.4.3 and -O0 -103168 potentially memory leak in coregrind/ume.c=20 -102039 bad permissions for mapped region at address 0xB7C73680 -101881 weird assertion problem -101543 Support fadvise64 syscalls -75247 x86_64/amd64 support (the biggest "bug" we have ever fixed) - -(3.0RC1: 27 July 05, vex r1303, valgrind r4283). -(3.0.0: 3 August 05, vex r1313, valgrind r4316). - |