Edit the release notes a bit and add our huge list of fixed bugs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5150 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/NEWS b/NEWS
index 1210106..3c359b5 100644
--- a/NEWS
+++ b/NEWS
@@ -1,46 +1,46 @@
-Release 3.1.0 (?? November 2005)
+Release 3.1.0 (25 November 2005)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-3.1.0 is a feature release with a number of significant improvements.
-In particular, AMD64 support is much improved, PPC32 support is good
-enough to be usable, and the handling of memory management and address
-space is much more robust.
+3.1.0 is a feature release with a number of significant improvements:
+AMD64 support is much improved, PPC32 support is good enough to be
+usable, and the handling of memory management and address space is
+much more robust. In detail:
-The details of these changes are as follows.
+- AMD64 support is much improved. The 64-bit vs. 32-bit issues in
+ 3.0.X have been resolved, and it should "just work" now in all
+ cases. On AMD64 machines both 64-bit and 32-bit versions of
+ Valgrind are built. The right version will be invoked
+ automatically, even when using --trace-children and mixing execution
+ between 64-bit and 32-bit executables. Also, many more instructions
+ are supported.
-- AMD64 support is much improved. The 64-bit vs. 32-bit issues in 3.0.0
- and 3.0.1 have been resolved, and it should "just work" now in all
- cases. On AMD64 machines both 64-bit and 32-bit versions of Valgrind
- are built. The right version will be invoked automatically, even when
- using --trace-children and mixing execution between 64-bit and 32-bit
- executables. Also, many more instructions are supported.
+- PPC32 support is now good enough to be usable. It should work with
+ all tools, but please let us know if you have problems. Three
+ classes of CPUs are supported: integer only (no FP, no Altivec),
+ which covers embedded PPC uses, integer and FP but no Altivec
+ (G3-ish), and CPUs capable of Altivec too (G4, G5).
-- PPC32 support is now sufficient to be usable. It should work with all
- tools, but please let us know if you have problems with it.
- [XXX: something about 405s? how's the Altivec support?]
-
-- The address space manager has been rewritten. As a result, Valgrind
- should be much more robust with programs that use large amounts of
- memory. There should be many fewer "memory exhausted" messages, and
- debug symbols should be read correctly on large (eg. 300MB+)
- executables. On 32-bit machines the full address space available
- to user programs (usually 3GB or 4GB) should be usable and fully
- utilised. On 64-bit machines up to 32GB of memory is available; when
- using Memcheck that means your program can use up to about 14GB of
- memory.
+- Valgrind's address space management has been overhauled. As a
+ result, Valgrind should be much more robust with programs that use
+ large amounts of memory. There should be many fewer "memory
+ exhausted" messages, and debug symbols should be read correctly on
+ large (eg. 300MB+) executables. On 32-bit machines the full address
+ space available to user programs (usually 3GB or 4GB) can be fully
+ utilised. On 64-bit machines up to 32GB of space is usable; when
+ using Memcheck that means your program can use up to about 14GB.
A side effect of this change is that Valgrind is no longer protected
against wild writes by the client. This feature was nice but relied
on the x86 segment registers and so wasn't portable.
- Most users should not notice, but as part of the address space
- manager change, the way Valgrind is built has been changed. Each tool
- is now built as a statically linked stand-alone executable, rather
- than as a shared object that is dynamically linked with the core. The
- "valgrind" program invokes the appropriate tool depending on the
- --tool option. This slightly increases the amount of disk space used
- by Valgrind, but it greatly simplified many things and removed
- Valgrind's dependence on glibc.
+ manager change, the way Valgrind is built has been changed. Each
+ tool is now built as a statically linked stand-alone executable,
+ rather than as a shared object that is dynamically linked with the
+ core. The "valgrind" program invokes the appropriate tool depending
+ on the --tool option. This slightly increases the amount of disk
+ space used by Valgrind, but it greatly simplified many things and
+ removed Valgrind's dependence on glibc.
Other user-visible changes:
@@ -49,6 +49,8 @@
- The --time-stamp option no longer gives an absolute date and time.
It now prints the time elapsed since the program began.
+- It should build with gcc-2.96.
+
The following are some user-visible changes that occurred in earlier
versions that may not have been announced, or were announced but not
widely realised. So we're mentioning them now.
@@ -69,7 +71,76 @@
BUGS FIXED:
-XXX... insert bugs fixed here
+109861 amd64 hangs at startup
+110301 ditto
+111554 valgrind crashes with Cannot allocate memory
+111809 Memcheck tool doesn't start java
+111901 cross-platform run of cachegrind fails on opteron
+113468 (vgPlain_mprotect_range): Assertion 'r != -1' failed.
+ 92071 Reading debugging info uses too much memory
+109744 memcheck loses track of mmap from direct ld-linux.so.2
+110183 tail of page with _end
+ 82301 FV memory layout too rigid
+ 98278 Infinite recursion possible when allocating memory
+108994 Valgrind runs out of memory due to 133x overhead
+115643 valgrind cannot allocate memory
+105974 vg_hashtable.c static hash table
+109323 ppc32: dispatch.S uses Altivec insn, which doesn't work on POWER.
+109345 ptrace_setregs not yet implemented for ppc
+110831 Would like to be able to run against both 32 and 64 bit
+ binaries on AMD64
+110829 == 110831
+111781 compile of valgrind-3.0.0 fails on my linux (gcc 2.X prob)
+112670 Cachegrind: cg_main.c:486 (handleOneStatement ...
+112941 vex x86: 0xD9 0xF4 (fxtract)
+110201 == 112941
+113015 vex amd64->IR: 0xE3 0x14 0x48 0x83 (jrcxz)
+113126 Crash with binaries built with -gstabs+/-ggdb
+104065 == 113126
+115741 == 113126
+113403 Partial SSE3 support on x86
+113541 vex: Grp5(x86) (alt encoding inc/dec) case 1
+113642 valgrind crashes when trying to read debug information
+113810 vex x86->IR: 66 0F F6 (66 + PSADBW == SSE PSADBW)
+113796 read() and write() do not work if buffer is in shared memory
+113851 vex x86->IR: (pmaddwd): 0x66 0xF 0xF5 0xC7
+114366 vex amd64 cannnot handle __asm__( "fninit" )
+114412 vex amd64->IR: 0xF 0xAD 0xC2 0xD3 (128-bit shift, shrdq?)
+114455 vex amd64->IR: 0xF 0xAC 0xD0 0x1 (also shrdq)
+115590: amd64->IR: 0x67 0xE3 0x9 0xEB (address size override)
+115953 valgrind svn r5042 does not build with parallel make (-j3)
+116057 maximum instruction size - VG_MAX_INSTR_SZB too small?
+116483 shmat failes with invalid argument
+102202 valgrind crashes when realloc'ing until out of memory
+109487 == 102202
+110536 == 102202
+112687 == 102202
+111724 vex amd64->IR: 0x41 0xF 0xAB (more BT{,S,R,C} fun n games)
+111748 vex amd64->IR: 0xDD 0xE2 (fucom)
+111785 make fails if CC contains spaces
+111829 vex x86->IR: sbb AL, Ib
+111851 vex x86->IR: 0x9F 0x89 (lahf/sahf)
+112031 iopl on AMD64 and README_MISSING_SYSCALL_OR_IOCTL update
+112152 code generation for Xin_MFence on x86 with SSE0 subarch
+112167 == 112152
+112789 == 112152
+112199 naked ar tool is used in vex makefile
+112501 vex x86->IR: movq (0xF 0x7F 0xC1 0xF) (mmx MOVQ)
+113583 == 112501
+112538 memalign crash
+113190 Broken links in docs/html/
+113230 Valgrind sys_pipe on x86-64 wrongly thinks file descriptors
+ should be 64bit
+113996 vex amd64->IR: fucomp (0xDD 0xE9)
+114196 vex x86->IR: out %eax,(%dx) (0xEF 0xC9 0xC3 0x90)
+114289 Memcheck fails to intercept malloc when used in an uclibc environment
+114756 mbind syscall support
+114757 Valgrind dies with assertion: Assertion 'noLargerThan > 0' failed
+114563 stack tracking module not informed when valgrind switches threads
+114564 clone() and stacks
+114565 == 114564
+115496 glibc crashes trying to use sysinfo page
+116200 enable fsetxattr, fgetxattr, and fremovexattr for amd64
Release 3.0.1 (29 August 2005)