|
From: Dirk M. <mu...@kd...> - 2003-11-27 11:44:22
|
CVS commit by mueller:
remove reference to --assume-2.4 option
M +0 -5 coregrind_core.html 1.19
--- valgrind/coregrind/docs/coregrind_core.html #1.18:1.19
@@ -866,9 +866,4 @@
</li><br><p>
- <li><code>--assume-2.4=no</code> [default]<br>
- <code>--assume-2.4=yes</code><br>
- <p>Assume we're running on a 2.4 kernel. Only needed for some
- distributions that are broken in obscure ways.
- </li><br><p>
</ul>
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-20 02:14:27
|
CVS commit by nethercote:
Update limitations section: merge some old changes from 2.0.0 branch, and some
new changes that only apply to HEAD.
M +9 -14 coregrind_core.html 1.20
--- valgrind/coregrind/docs/coregrind_core.html #1.19:1.20
@@ -1187,11 +1187,6 @@
<ul>
- <li>No MMX, SSE, SSE2, 3DNow instructions. If the translator
- encounters these, Valgrind will simply give up. It may be
- possible to add support for them at a later time. Intel added a
- few instructions such as "cmov" to the integer instruction set
- on Pentium and later processors, and these are supported.
- Nevertheless it's safest to think of Valgrind as implementing
- the 486 instruction set.</li>
+ <li>No support for 3DNow instructions. If the translator encounters
+ these, Valgrind will simply give up.</li>
<p>
@@ -1215,5 +1210,10 @@
<li>If your program does its own memory management, rather than
using malloc/new/free/delete, it should still work, but
- Valgrind's error checking won't be so effective.</li>
+ Valgrind's error checking won't be so effective.
+ If you describe your program's memory management scheme
+ using "client requests" (Section 3.7 of this manual),
+ valgrind can do better. Nevertheless, using malloc/new
+ and free/delete is still the best approach.
+ </li>
<p>
@@ -1239,5 +1239,5 @@
demand. So it's possible, although unlikely, that a program
will fall over with a message to that effect. If this happens,
- please mail me ALL the details printed out, so I can try and
+ please report ALL the details printed out, so we can try and
implement the missing feature.</li>
<p>
@@ -1248,9 +1248,4 @@
<p>
- <li>You can't Valgrind-ize statically linked binaries. Valgrind
- relies on the dynamic-link mechanism to gain control at
- startup.</li>
- <p>
-
<li>Memory consumption of your program is majorly increased whilst
running under Valgrind. This is due to the large amount of
|
|
From: Jeremy F. <je...@go...> - 2004-01-21 01:23:07
|
CVS commit by fitzhardinge:
Small update about unimplemented instructions.
M +2 -1 coregrind_core.html 1.21
--- valgrind/coregrind/docs/coregrind_core.html #1.20:1.21
@@ -1188,5 +1188,6 @@
<ul>
<li>No support for 3DNow instructions. If the translator encounters
- these, Valgrind will simply give up.</li>
+ these, Valgrind will generate a SIGILL when the instruction is
+ executed.</li>
<p>
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-22 08:58:21
|
CVS commit by nethercote:
In response to bug #85665, clarify what --trace-children=yes does.
M +7 -1 coregrind_core.html 1.31
--- valgrind/coregrind/docs/coregrind_core.html #1.30:1.31
@@ -523,6 +523,12 @@
<code>--trace-children=yes</code>
<p>When enabled, Valgrind will trace into child processes. This
- is confusing and usually not what you want, so is disabled by
+ is confusing and often not what you want, so is disabled by
default.
+
+ <p>Note that the name of this option is slightly misleading.
+ It actually controls whether programs started with
+ <code>exec()</code> are run under Valgrind's control. If your
+ program calls <code>fork()</code>, both the parent and the child
+ will run under Valgrind's control.
</li><br><p>
|
|
From: Julian S. <js...@ac...> - 2004-08-31 00:13:18
|
CVS commit by jseward:
Add comments about limitations wrt self-modifying code.
M +18 -3 coregrind_core.html 1.34
--- valgrind/coregrind/docs/coregrind_core.html #1.33:1.34
@@ -1115,6 +1115,6 @@
We now use the standard Unix <code>./configure</code>,
<code>make</code>, <code>make install</code> mechanism, and I have
-attempted to ensure that it works on machines with kernel 2.2 or 2.4
-and glibc 2.1.X or 2.2.X. I don't think there is much else to say.
+attempted to ensure that it works on machines with kernel 2.4 or 2.6
+and glibc 2.2.X or 2.3.X. I don't think there is much else to say.
There are no options apart from the usual <code>--prefix</code> that
you should give to <code>./configure</code>.
@@ -1169,5 +1169,5 @@
<p>Valgrind will run x86-GNU/Linux ELF dynamically linked binaries, on
-a kernel 2.2.X or 2.4.X system, subject to the following constraints:
+a kernel 2.4.X or 2.6.X system, subject to the following constraints:
<ul>
@@ -1242,4 +1242,19 @@
translations when running (eg) a web browser.
</li>
+ <p>
+
+ <li>Valgrind can handle dynamically-generated code just fine.
+ However, if you regenerate code over the top of old code
+ (ie. at the same memory addresses) Valgrind will not realise the
+ code has changed, and will run its old translations, which will
+ be out-of-date. You need to use the VALGRIND_DISCARD_TRANSLATIONS
+ client request in that case. For the same reason gcc's
+ <a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html">
+ trampolines for nested functions</a> are currently
+ unsupported, see <a href="http://bugs.kde.org/show_bug.cgi?id=69511">
+ bug 69511</a>.
+ </li>
+ <p>
+
</ul>
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 18:34:08
|
CVS commit by nethercote:
Fix incorrect info about using GDB on Valgrind.
MERGE TO STABLE
M +2 -27 coregrind_tools.html 1.4
--- valgrind/coregrind/docs/coregrind_tools.html #1.3:1.4
@@ -548,31 +548,6 @@
If you want to debug C functions used by your tool, you can attach GDB to
-Valgrind with some effort:
-<ul>
- <li>Enable the following code in <code>coregrind/vg_main.c</code> by
- changing <code>if (0)</code> into <code>if (1)</code>:
-<pre>
- /* Hook to delay things long enough so we can get the pid and
- attach GDB in another shell. */
- if (0) {
- Int p, q;
- for (p = 0; p < 50000; p++)
- for (q = 0; q < 50000; q++) ;
- }
-</pre>
- </li><p>
- and rebuild Valgrind.
-
- <li>Then run:
- <blockquote><code>valgrind <i>prog</i></code></blockquote>
-
- Valgrind starts the program, printing its process id, and then delays for
- a few seconds (you may have to change the loop bounds to get a suitable
- delay).</li><p>
-
- <li>In a second shell run:
-
- <blockquote><code>gdb <i>prog</i> <i>pid</i></code></blockquote></li><p>
-</ul>
+Valgrind with some effort; see the file <code>README_DEVELOPERS</code> in
+CVS for instructions.<p>
GDB may be able to give you useful information. Note that by default
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-10 01:05:21
|
CVS commit by nethercote:
De-document now-defunct command line options.
M +0 -16 coregrind_core.html 1.36
--- valgrind/coregrind/docs/coregrind_core.html #1.35:1.36
@@ -798,20 +798,4 @@
</ul>
</li><br><p>
-
- <li><code>--signal-polltime=<time></code> [default=50]<br>
- <p>How often to poll for signals (in milliseconds). Only applies for
- older kernels that need signal routing.
- </li><br><p>
-
- <li><code>--lowlat-signals=no</code> [default]<br>
- <code>--lowlat-signals=yes</code><br>
- <p>Improve wake-up latency when a thread receives a signal.
- </li><br><p>
-
- <li><code>--lowlat-syscalls=no</code> [default]<br>
- <code>--lowlat-syscalls=yes</code><br>
- <p>Improve wake-up latency when a thread's syscall completes.
- </li><br><p>
-
</ul>
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 05:42:26
|
CVS commit by nethercote:
Update docs for option default changes.
M +3 -1 coregrind_core.html 1.38
--- valgrind/coregrind/docs/coregrind_core.html #1.37:1.38
@@ -488,4 +488,6 @@
</ul>
+If you omit this option, the default tool is Memcheck.
+
<h4>Basic Options</h4>
These options work with all tools.
@@ -586,5 +588,5 @@
</li><br><p>
- <li><code>--num-callers=<number></code> [default=4]<br>
+ <li><code>--num-callers=<number></code> [default=12]<br>
<p>By default, Valgrind shows four levels of function call names
to help you identify program locations. You can change that
|
|
From: Oswald B. <os...@kd...> - 2005-03-04 05:56:20
|
CVS commit by ossi:
fix update. diff -u is something wonderful ... :)
M +1 -1 coregrind_core.html 1.39
--- valgrind/coregrind/docs/coregrind_core.html #1.38:1.39
@@ -589,5 +589,5 @@
<li><code>--num-callers=<number></code> [default=12]<br>
- <p>By default, Valgrind shows four levels of function call names
+ <p>By default, Valgrind shows twelve levels of function call names
to help you identify program locations. You can change that
number with this option. This can help in determining the
|