|
From: Julian S. <ju...@va...> - 2005-07-19 13:27:18
|
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 |
|
From: Crispin F. <val...@fl...> - 2005-07-19 16:54:15
|
On Tue, 2005-07-19 at 14:27 +0100, Julian Seward wrote: > - pls download, build, test, report critical bugs I downloaded this, and gave it a test with the Zeus Web Server (www.zeus.com): - From basic tests, it appears to me that it is quite a bit slower (2.4 SVN starts up the server in 11 seconds, whereas 3.0 SVN takes 23 seconds). - More seriously, 3.0 seems to have lots of: ==903== Use of uninitialised value of size 4 ==903== at 0x81AC95E: (within zeus.web) and these don't have any backtrace at all, whereas when it complains that the read was inside a malloc, I get a backtrace just fine (this is with debug builds) - Interestingly, 2.4 doesn't report _any_ of these uninitialised values, and when running under 3.0 the server segfaults whereas it doesn't under 2.4 or without valgrind. I am wondering if 3.0 and 2.4 report different cpu capabilities (such as mmx, sse etc) and one of the libraries we use is using different code paths. That might explain the uninitialised values, although I don't see how that could explain the lack of backtraces. I realise that this isn't 100% helpful without a testcase, but extracting the code for a testcase as the library I believe is causing problems is something we don't have the code for :-( (Linux/x86) Crispin |
|
From: Julian S. <ju...@va...> - 2005-07-19 17:22:00
|
> - From basic tests, it appears to me that it is quite a bit slower (2.4 > SVN starts up the server in 11 seconds, whereas 3.0 SVN takes 23 > seconds). The new JIT is a lot slower than the 2.4 one, unfortunately. Most of the startup delay is likely to be translation time. > - Interestingly, 2.4 doesn't report _any_ of these uninitialised values, > and when running under 3.0 the server segfaults whereas it doesn't under > 2.4 or without valgrind. Euh, that sucks. Do you get any useful logging output just before the crash? Does it still crash with --tool=none? What about with --tool=none --vex-iropt-level=0 ? > > I am wondering if 3.0 and 2.4 report different cpu capabilities (such as > mmx, sse etc) Quite possibly. Rerun with -v -v and look for a line like this: --5075-- Host CPU: arch = X86, subarch = x86-sse2 J |
|
From: Josef W. <Jos...@gm...> - 2005-07-20 02:17:39
|
Hi Julian,
On Tuesday 19 July 2005 15:27, Julian Seward wrote:
> - JosefW: what is the calltree status for the 3 line? It would be
> good to ensure that calltree/kcachegrind works well with 3.0.
I just started looking at it ;-)
I first tried to write a configure.in which checks if valgrind headers are
installed and a tool can be compiled.
1) For which OS/ARCH should the external tool be compiled?
Are installed header files specific for an installation or not?
I think I should use the OS/ARCH defined in the installed valgrind.pc file. Is
this the correct way?
2) For the tool compilation check in configure, I use the headers from
none/nl_main.c, i.e.
#include "pub_tool_basics.h"
#include "pub_tool_libcassert.h"
#include "pub_tool_tooliface.h"
I get the following errors in the configure run:
In file included from conftest.c:15:
/usr/local/include/valgrind/pub_tool_basics.h:47:31: libvex_basictypes.h: No
such file or directory
/usr/local/include/valgrind/pub_tool_basics.h:56:20: config.h: No such file or
directory
I think that vex should install its public header files in the same directory
as valgrind.
Furthermore, I think that public header files of VG should not
include any config.h. If I copy the config.h into $prefix/include/valgrind,
the configure goes through, but in the config.log I see
In file included from /usr/local/include/valgrind/pub_tool_basics.h:56,
from conftest.c:15:
/usr/local/include/valgrind/config.h:101:1: warning: "PACKAGE" redefined
conftest.c:8:1: warning: this is the location of the previous definition
...
So I don't thing this is the right way.
That's for now. I'm quite sure I have something running in the next days...
Cheers,
Josef
PS: For cachegrind/cg-x86, I have an addition:
--- cachegrind/cg-x86.c 2005-07-01 13:27:20.000000000 +0200
+++ src/cg-x86.c 2005-07-20 01:47:47.000000000 +0200
@@ -158,6 +158,8 @@ Int Intel_cache_info(Int level, cache_t*
case 0x7a: *L2c = (cache_t) { 256, 8, 64 }; L2_found = True; break;
case 0x7b: *L2c = (cache_t) { 512, 8, 64 }; L2_found = True; break;
case 0x7c: *L2c = (cache_t) { 1024, 8, 64 }; L2_found = True; break;
+ /* Pentium M Dothan */
+ case 0x7d: *L2c = (cache_t) { 2048, 8, 64 }; L2_found = True; break;
case 0x7e: *L2c = (cache_t) { 256, 8, 128 }; L2_found = True; break;
case 0x81: *L2c = (cache_t) { 128, 8, 32 }; L2_found = True; break;
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 05:28:29
|
On Wed, 20 Jul 2005, Josef Weidendorfer wrote: > 1) For which OS/ARCH should the external tool be compiled? > I think I should use the OS/ARCH defined in the installed valgrind.pc file. Is > this the correct way? Sounds reasonable to me. > Are installed header files specific for an installation or not? I don't understand the question, sorry... > 2) For the tool compilation check in configure, I use the headers from > none/nl_main.c, i.e. > > #include "pub_tool_basics.h" > #include "pub_tool_libcassert.h" > #include "pub_tool_tooliface.h" Sounds ok. > I think that vex should install its public header files in the same directory > as valgrind. Yes, good point. > Furthermore, I think that public header files of VG should not > include any config.h. Hmm, it looks like config.h was previously included only in core.h. I'll investigate. > PS: For cachegrind/cg-x86, I have an addition: Thanks, I'll add it. N |
|
From: Josef W. <Jos...@gm...> - 2005-07-20 08:32:20
|
On Wednesday 20 July 2005 06:28, Nicholas Nethercote wrote: > On Wed, 20 Jul 2005, Josef Weidendorfer wrote: > > 1) For which OS/ARCH should the external tool be compiled? > > I think I should use the OS/ARCH defined in the installed valgrind.pc > > file. Is this the correct way? > > Sounds reasonable to me. What happens if you want to have a dual installation on an Opteron, i.e. both Valgrind x86 and x86_64? This works now out of the box if you use different install prefixes (and separate installations), but that is a strange installation. Some convention here seems to be to add a "64" at the end of directory/file names. E.g. I could search for a valgrind64.pc file. Or should we leave this problem to distributors? > > Are installed header files specific for an installation or not? > > I don't understand the question, sorry... Sorry. The question was meant to ask if the header files installed have anything specific to the architecture used for compilation, or if they are common to all supported architectures. > > I think that vex should install its public header files in the same > > directory as valgrind. > > Yes, good point. As vex is obviously part of valgrinds tool API, but vex is a library on its own now: can external tools assume that valgrinds tool API version is incremented whenever there is an change in vex's API? > > Furthermore, I think that public header files of VG should not > > include any config.h. > > Hmm, it looks like config.h was previously included only in core.h. I'll > investigate. Thinking loud: a config.h file only has system info needed for compilation of the current package (i.e valgrind). A dependent package (callgrind) should do its own configure checks needed for its compilation. I suppose you should include the config.h directly in *.c files where a given configure check is needed (or package name/version defines). Josef |
|
From: Tom H. <to...@co...> - 2005-07-20 08:39:36
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Wednesday 20 July 2005 06:28, Nicholas Nethercote wrote:
>> On Wed, 20 Jul 2005, Josef Weidendorfer wrote:
>> > 1) For which OS/ARCH should the external tool be compiled?
>> > I think I should use the OS/ARCH defined in the installed valgrind.pc
>> > file. Is this the correct way?
>>
>> Sounds reasonable to me.
>
> What happens if you want to have a dual installation on an Opteron, i.e. both
> Valgrind x86 and x86_64? This works now out of the box if you use different
> install prefixes (and separate installations), but that is a strange
> installation.
We haven't decided how to handle this yet - whether to require people
to build two versions or whether building valgrind on amd64 will build
support for 32 bit binaries somehow.
If two versions are required then the naming scheme has yet to be
fixed upon.
The ultimate would be a 64 bit stage2 that could run 32 bit binaries
so that shadow memory and such could be outside the 32 bit address
space to leave more room for the client. I think that is likely to be
quite hard however.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 13:11:12
|
On Wed, 20 Jul 2005, Josef Weidendorfer wrote: > What happens if you want to have a dual installation on an Opteron, i.e. both > Valgrind x86 and x86_64? This works now out of the box if you use different > install prefixes (and separate installations), but that is a strange > installation. > Some convention here seems to be to add a "64" at the end of directory/file > names. E.g. I could search for a valgrind64.pc file. > > Or should we leave this problem to distributors? I don't think we have a clear solution to this problem. > Sorry. The question was meant to ask if the header files installed have > anything specific to the architecture used for compilation, or if they are > common to all supported architectures. There are some arch-specific files, namely the vki*.h ones, and some of the others have #ifdefs that depend on the architecture (eg. pub_tool_basics.h). Is this a problem? > As vex is obviously part of valgrinds tool API, but vex is a library on its > own now: can external tools assume that valgrinds tool API version is > incremented whenever there is an change in vex's API? Yes. > Thinking loud: a config.h file only has system info needed for compilation of > the current package (i.e valgrind). A dependent package (callgrind) should do > its own configure checks needed for its compilation. > I suppose you should include the config.h directly in *.c files where a given > configure check is needed (or package name/version defines). I'm wary of including only in the places where it is needed. This is because a lot of the time if you forget to include it in one of these places, you might not get an obvious error -- ie. some constant won't be defined that should be defined, and it will silently cause misbehaviour. I think I'll just include it in pub_core_basics.h rather than pub_tool_basics.h; that's basically how it used to be (ie. we included it in core.h rather than tool.h). N |