From: Julian Seward Date: Sun, 16 Aug 2009 22:49:53 +0000 (+0000) Subject: Minor changes w.r.t. --read-var-info=, threading support, and X-Git-Tag: svn/VALGRIND_3_5_0~20 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d5b1173d7b38b88582b9a7fcc8751aad2418049b;p=thirdparty%2Fvalgrind.git Minor changes w.r.t. --read-var-info=, threading support, and supported glibc versions. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10830 --- diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index a3fa73c64d..924c75e46f 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -1346,11 +1346,12 @@ need to use these. - When enabled, Valgrind will read information about variables from - debug info. This slows Valgrind down and makes it use more memory, but - for the tools that can take advantage of it (Memcheck, Helgrind, DRD) it - can result in more precise error messages. For example, here are some - standard errors issued by Memcheck: + When enabled, Valgrind will read information about + variable types and locations from DWARF3 debug info. + This slows Valgrind down and makes it use more memory, but for + the tools that can take advantage of it (Memcheck, Helgrind, + DRD) it can result in more precise error messages. For example, + here are some standard errors issued by Memcheck: Support for Threads -The main thing to point out with respect to multithreaded programs is +Threaded programs are fully supported. + +The main thing to point out with respect to threaded programs is that your program will use the native threading library, but Valgrind -serialises execution so that only one (kernel) thread is running at a time. -This approach avoids the horrible implementation problems of implementing a -truly multiprocessor version of Valgrind, but it does mean that threaded -apps run only on one CPU, even if you have a multiprocessor machine. - -Valgrind schedules your program's threads in a round-robin fashion, -with all threads having equal priority. It switches threads -every 100000 basic blocks (on x86, typically around 600000 -instructions), which means you'll get a much finer interleaving -of thread executions than when run natively. This in itself may -cause your program to behave differently if you have some kind of -concurrency, critical race, locking, or similar, bugs. In that case -you might consider using the tools Helgrind and/or DRD to track them -down. +serialises execution so that only one (kernel) thread is running at a +time. This approach avoids the horrible implementation problems of +implementing a truly multithreaded version of Valgrind, but it does +mean that threaded apps run only on one CPU, even if you have a +multiprocessor or multicore machine. + +Valgrind doesn't schedule the threads itself. It merely ensures +that only one thread runs at once, using a simple locking scheme. The +actual thread scheduling remains under control of the OS kernel. What +this does mean, though, is that your program will see very different +scheduling when run on Valgrind than it does when running normally. +This is both because Valgrind is serialising the threads, and because +the code runs so much slower than normal. + +This difference in scheduling may cause your program to behave +differently, if you have some kind of concurrency, critical race, +locking, or similar, bugs. In that case you might consider using the +tools Helgrind and/or DRD to track them down. On Linux, Valgrind also supports direct use of the clone system call, @@ -1624,7 +1631,7 @@ will create a core dump in the usual way. make, make install mechanism, and we have attempted to ensure that it works on machines with kernel 2.4 or 2.6 and glibc -2.2.X to 2.9.X. Once you have completed +2.2.X to 2.10.X. Once you have completed make install you may then want to run the regression tests with make regtest.