|
From: Yeshurun, M. <mei...@in...> - 2005-07-19 13:40:19
|
I think Valgrind is a fabulous achievement. But regarding the 3.0 line, I think it should be made more clear that this version still doesn't take advantage of the large address space that is available for processes on AMD64 platforms. I think this is the main reason why people are so eagerly waiting for this version. Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Julian Seward Sent: Tuesday, July 19, 2005 4:28 PM To: val...@li... Cc: val...@li...; Jos...@gm... Subject: [Valgrind-users] Release plan for Valgrind 3.0 Over the past year, a tremendous amount of development effort has gone into the Valgrind 3 line. It now runs on x86 and amd64 quite usably, and ppc32 (Linux) is looking promising. There have been a large number of of bug fixes, functionality improvments, and restructuring of the source code to enhance accessibility and maintainability. A GUI (Valkyrie) is also under development, and we plan to make coordinated releases of that along with Valgrind in the future. The time for a Valgrind-3.0 release draws near. I propose to have a release candidate (feature freeze) by next Monday 25 July, with a possible release on Monday 1 Aug. Valgrind-3.0 is already stable and usable on x86 and amd64. If you haven't already done so, please checkout and build it (easy: see http://www.valgrind.org/devel/cvs_svn.html), test it on whatever applications are critical for you, and let us know of any critical breakage. The more people who do this now, the better quality 3.0 release we will have. Outstanding issues which I'm aware of, and which need to be fixed, are: - decide on a version numbering / branch management scheme - decide about how to handle dependency on libvex - minor tweaks to XML output and to logfile naming (me) - fix: #88116 (x86, "enter" variant causes assertion) #96542 (x86, possible assertions with push variants) #87263 (x86, segment stuff) #103594 (x86, FICOM) INT/INT3 insns (x86) Missing 0xA3 insn (amd64) All of these I'll chase. - Update documentation (me, + ??) I'm sure there are other things I've forgotten/am not aware of. Much effort recently has gone into making ppc32-linux work well, but that target is not yet really usable. In particular there are problems with getting a low noise level from Memcheck, and some difficulties with floating point. Work to resolve these is in progress, but I do not know if it will be successful in the limited time before the release. We are already overdue for a 3.0 release and I am reluctant to delay it further in order to have ppc32 support. Therefore I propose to present 3.0 as a production-quality release for x86 and amd64 only, and if ppc32 happens to be usable, well that's an extra bonus. Obviously it would be wonderful to have ppc32 usable too, and I will endeavour to cause that to be the case. So: - pls download, build, test, report critical bugs - JosefW: what is the calltree status for the 3 line? It would be good to ensure that calltree/kcachegrind works well with 3.0. J ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dallman, J. <jg...@ug...> - 2005-07-19 14:42:05
|
Dennis Lubert writes: > ... I think most applications and developers don't use 64Bit=20 > because of the big address space.=20 Well, actually, that is the whole point of 64-bit - the address=20 space. However, since all our routine test cases have to be able=20 to run on 32-bit platforms as well, a 64-bit Valgrind with=20 about as much usable memory as for a 32-bit platform would be=20 useful.=20 > and even if, most of them will be able to split up their programs=20 > into little test cases for which valgrind3 will be of great use. I think you're being just a wee bit optimistic here.=20 --=20 John Dallman, Parasolid Porting Engineer, +44-1223-371554=20 |
|
From: Julian S. <js...@ac...> - 2005-07-19 14:07:31
|
> I think Valgrind is a fabulous achievement. But regarding the 3.0 line, > I think it should be made more clear that this version still doesn't > take advantage of the large address space that is available for > processes on AMD64 platforms. There are various limitations etc which will be documented, and this will be amongst them. It's not a reason for delaying 3.0 though. J |
|
From: Dennis L. <pla...@in...> - 2005-07-19 14:32:13
|
At 16:08 19.07.2005, Julian Seward wrote: > > I think Valgrind is a fabulous achievement. But regarding the 3.0 line, > > I think it should be made more clear that this version still doesn't > > take advantage of the large address space that is available for > > processes on AMD64 platforms. > >There are various limitations etc which will be documented, and this >will be amongst them. It's not a reason for delaying 3.0 though. I agree. As long as valgrind3 is usable, it has been a great tool which helped us developing/porting applications for 64Bit. In my opinion address space limitation should be fixed quite soon, but is no reason to delay a release, since I think most applications and developers dont use 64Bit because of the big address space. And even if, most of them will be able to split up their programs into little test cases for which valgrind3 will be of great use. greets Dennis Carpe quod tibi datum est |