You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(6) |
2
(3) |
3
|
4
(3) |
5
(10) |
6
(4) |
7
(5) |
|
8
(1) |
9
(3) |
10
(11) |
11
(18) |
12
(13) |
13
(4) |
14
(11) |
|
15
(12) |
16
(6) |
17
(1) |
18
(13) |
19
(14) |
20
(12) |
21
(3) |
|
22
(17) |
23
(18) |
24
(17) |
25
(24) |
26
(15) |
27
(7) |
28
(23) |
|
29
(31) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-07 20:16:18
|
CVS commit by nethercote: whoops again M +1 -0 users.html 1.31 --- devel-home/valgrind/users.html #1.30:1.31 @@ -284,4 +284,5 @@ <h3>Internet</h3> +<dl> <dt><a href="http://messenger.yahoo.com/messenger/download/unix.html">Yahoo! Messenger</a> <dd>A free instant messaging service. |
|
From: Nicholas N. <nj...@ca...> - 2004-02-07 20:15:38
|
CVS commit by nethercote: whoops M +1 -1 users.html 1.30 --- devel-home/valgrind/users.html #1.29:1.30 @@ -35,5 +35,5 @@ <dt><a href="http://mozilla.org/products/thunderbird/">Mozilla Thunderbird</a> <dd>A powerful email and newsgroup client derived from the Mozilla suite. -<dl> +</dl> |
|
From: Nicholas N. <nj...@ca...> - 2004-02-07 20:14:39
|
CVS commit by nethercote: Changed category structure a bit. Added a short "highlights" list at the top of really well-known projects. Added amaroK, Boost. M +85 -62 users.html 1.29 --- devel-home/valgrind/users.html #1.28:1.29 @@ -6,6 +6,12 @@ The following projects use or have used Valgrind. +<p> +The short list: OpenOffice, StarOffice, Mozilla, Opera, KDE, GNOME, Evolution, +MySQL, PostgreSQL, Perl, PHP, Samba, Nasa Mars Lander software, The GIMP, Ogg +Vorbis, Battlefield 1942... +<p> +The long list... -<h3>Desktop</h3> +<h3>Office Software</h3> <dl> <dt><a href="http://openoffice.org">OpenOffice</a> @@ -17,32 +23,7 @@ <dd>A commercial multi-platform office productivity suite, based on OpenOffice. -<dt><a href="http://www.gimp.org">The GIMP</a> -<dd>The GNU Image Manipulation Program. - -<dt><a href="http://www.lysator.liu.se/~alla/dia/">Dia</a> -<dd>A diagram creator, particularly suited to drawing simple circuit diagrams, - and more. -</dl> - -<h3>KDE</h3> -<dl> -<dt><a href="http://www.kde.org">KDE</a> -<dd>An open source graphical desktop environment for Unix workstations. - <dt><a href="http://www.koffice.org">KOffice</a> <dd>A multi-application, integrated office suite. -<dt><a href="http://www.konqueror.org">Konqueror</a> -<dd>A web browser, file manager, and universal document viewing application. - -<dt><a href="http://www.trolltech.com/products/qt/">Qt by Trolltech</a> -<dd>A multi-platform, C++ application development framework. -</dl> - -<h3>GNOME</h3> -<dl> -<dt><a href="http://www.gnome.org">GNOME</a> -<dd>A desktop environment and developer platform for Unix and Linux systems. - <dt><a href="http://www.gnumeric.org">Gnumeric</a> <dd>A replacement for proprietary spreadsheets. @@ -52,9 +33,10 @@ task-list system. -<dt><a href="http://xmlsoft.org/">libxml2/libxslt</a> -<dd>GNOME's multi-platform XML C parser and toolkit. -</dl> +<dt><a href="http://mozilla.org/products/thunderbird/">Mozilla Thunderbird</a> +<dd>A powerful email and newsgroup client derived from the Mozilla suite. +<dl> -<h3>Web, Internet and Email</h3> + +<h3>Web Browsers</h3> <dl> <dt><a href="http://www.mozilla.org">Mozilla</a> @@ -64,10 +46,10 @@ <dd>A lean, fast web browser derived from the Mozilla suite. -<dt><a href="http://mozilla.org/products/thunderbird/">Mozilla Thunderbird</a> -<dd>A powerful email and newsgroup client derived from the Mozilla suite. - <dt><a href="http://www.opera.com">Opera</a> <dd>A fast, multi-platform web browser. +<dt><a href="http://www.konqueror.org">Konqueror</a> +<dd>A web browser, file manager, and universal document viewing application. + <dt><a href="http://galeon.sf.net">Galeon</a> <dd>A web browser for GNOME that uses Mozilla's rendering engine. @@ -75,19 +57,7 @@ <dt><a href="http://www.emsoftltd.com/index.php?action=embrowser">Embrowser</a> <dd>A small extensible web browser for internet appliances. - -<dt><a href="http://messenger.yahoo.com/messenger/download/unix.html">Yahoo! Messenger</a> -<dd>A free instant messaging service. - -<dt><a href="http://pan.rebelbase.com">Pan</a> -<dd>A newsreader supporting offline newsreading, article filtering, and - multiple connections. - -<dt><a href="http://www.pldaniels.com/ripmime">ripMIME</a> -<dd>An email decoding engine and library. - -<dt><a href="http://bidwatcher.sf.net">Bidwatcher</a> -<dd>An eBay auction listing tracker. </dl> + <h3>Databases and Search Engines</h3> <dl> @@ -119,4 +89,5 @@ </dl> + <h3>Scientific</h3> <dl> @@ -164,4 +135,5 @@ </dl> + <h3>Simulation</h3> <dl> @@ -177,4 +149,5 @@ </dl> + <h3>Compilers and Interpreters</h3> <dl> @@ -193,5 +166,6 @@ </dl> -<h3>Programming Tools</h3> + +<h3>Development Tools</h3> <dl> <dt><a href="http://www.gnu.org/software/ddd/">GNU ddd</a> @@ -202,13 +176,7 @@ <dd>A system-wide, kernel- and user-space profiler for Linux. -<dt><a href="http://www.uclibc.org">uClibc</a> -<dd>A compact C library for embedded systems. - <dt><a href="http://www.venge.net/monotone/">Monotone</a> <dd>A free, distributed version control system. -<dt><a href="http://eboxy.sf.net">eboxy</a> -<dd>A tool for creating graphical user interfaces for set-top boxes. - <dt><a href="http://www.froglogic.com/squish/">Squish</a> <dd>A cross-platform automated GUI testing framework for Qt/C++ applications. @@ -219,6 +187,35 @@ <dt><a href="http://www.cmake.org">CMake</a> <dd>A cross-platform, open-source make system. + +<dt><a href="http://eboxy.sf.net">eboxy</a> +<dd>A tool for creating graphical user interfaces for set-top boxes. </dl> + +<h3>Development Environments and Libraries</h3> +<dl> +<dt><a href="http://www.kde.org">KDE</a> +<dd>An open source graphical desktop environment for Unix workstations. + +<dt><a href="http://www.gnome.org">GNOME</a> +<dd>A desktop environment and developer platform for Unix and Linux systems. + +<dt><a href="http://www.trolltech.com/products/qt/">Qt by Trolltech</a> +<dd>A multi-platform, C++ application development framework. + +<dt><a href="http://opie.handhelds.org">Opie</a> +<dd>A graphical user environment for PDAs and other Linux devices. + +<dt><a href="http://www.uclibc.org">uClibc</a> +<dd>A compact C library for embedded systems. + +<dt><a href="http://xmlsoft.org/">libxml2/libxslt</a> +<dd>GNOME's multi-platform XML C parser and toolkit. + +<dt><a href="http://www.boost.org">Boost C++ libraries</a> +<dd>A collection of portable C++ source libraries. +</dl> + + <h3>Audio/Video</h3> <dl> @@ -241,6 +238,10 @@ <dt><a href="http://www.uchian.pwp.blueyonder.co.uk/kdenlive.html">Kdenlive</a> <dd>Video editing suite. + +<dt><a href="http://amarok.sourceforge.net/">amaroK</a> +<dd>A KDE media player.</a> </dl> + <h3>System</h3> <dl> @@ -253,6 +254,13 @@ (<a href="http://www.securiteam.com/unixfocus/6P00D208UC.html">Example</a> bug found.) + +<dt><a href="http://www.ntop.org">ntop</a> +<dd>A network traffic probe that shows network usage. + +<dt><a href="http://synce.sf.net">SynCE</a> +<dd>A WinCE communications layer. </dl> + <h3>Games</h3> <dl> @@ -274,6 +282,30 @@ </dl> + +<h3>Internet</h3> +<dt><a href="http://messenger.yahoo.com/messenger/download/unix.html">Yahoo! Messenger</a> +<dd>A free instant messaging service. + +<dt><a href="http://pan.rebelbase.com">Pan</a> +<dd>A newsreader supporting offline newsreading, article filtering, and + multiple connections. + +<dt><a href="http://www.pldaniels.com/ripmime">ripMIME</a> +<dd>An email decoding engine and library. + +<dt><a href="http://bidwatcher.sf.net">Bidwatcher</a> +<dd>An eBay auction listing tracker. +</dl> + + <h3>Other</h3> <dl> +<dt><a href="http://www.gimp.org">The GIMP</a> +<dd>The GNU Image Manipulation Program. + +<dt><a href="http://www.lysator.liu.se/~alla/dia/">Dia</a> +<dd>A diagram creator, particularly suited to drawing simple circuit diagrams, + and more. + <dt><a href="http://www.sportvision.com">SportVision</a> <dd>Various tools for virtual enhancements to live TV sports broadcasts. @@ -290,15 +322,6 @@ access from C, C++, Java, Perl, Python. -<dt><a href="http://opie.handhelds.org">Opie</a> -<dd>A graphical user environment for PDAs and other Linux devices. - <dt><a href="http://www.gtk-papaya.org">Papaya</a> <dd>A GTK+-2.0 MUD client for UNIX and Windows. - -<dt><a href="http://synce.sf.net">SynCE</a> -<dd>A WinCE communications layer. - -<dt><a href="http://www.ntop.org">ntop</a> -<dd>A network traffic probe that shows network usage. </dl> |
|
From: Eyal L. <ey...@ey...> - 2004-02-07 02:18:29
|
Running latest cvs. Debian 3.0r2, gcc 1.95.3, Linux 2.4.25-pre8 The following failure does not happen always. Actually, in most runs all is fine, but once in a while I get this failure. A program (sched) is execing another (init) which then spawns (fork/exec) another. The failure is always in this last execvp() before the target executable starts. All programs create a new thread as they start and this thread does everything. main() is just waiting on a join(). Is this a known problem? Anything I can try? valgrind: vg_proxylwp.c:972 (proxy_wait): Assertion `*status == proxy->exitcode' failed. ==17532== at 0xB802ACF8: vgPlain_skin_assert_fail (in /data2/usr/local/lib/valgrind/stage2) ==17532== by 0xB802ACF7: assert_fail (vg_mylibc.c:1157) ==17532== by 0xB802AD35: vgPlain_core_assert_fail (vg_mylibc.c:1168) ==17532== by 0xB802DCC3: proxy_wait (vg_proxylwp.c:972) ==17532== by 0xB802DEB1: vgPlain_proxy_delete (vg_proxylwp.c:1067) ==17532== by 0xB800E22C: vgPlain_nuke_all_threads_except (vg_scheduler.c:1451) ==17532== by 0xB803B80E: before_execve (vg_syscalls.c:1847) ==17532== by 0xB80419ED: vgPlain_pre_syscall (vg_syscalls.c:5351) ==17532== by 0xB800D535: sched_do_syscall (vg_scheduler.c:716) ==17532== by 0xB800DC25: vgPlain_scheduler (vg_scheduler.c:1149) ==17532== by 0xB8025DBB: main (vg_main.c:3005) sched status: Thread 2: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==17532== at 0x3C917F06: execve (in /lib/libc-2.2.5.so) ==17532== by 0x3C9181F1: execvp (in /lib/libc-2.2.5.so) ==17532== by 0x3C7AE765: ??? (exec.c:294) ==17532== by 0x3C7AE982: skzz15 (exec.c:517) ==17532== by 0x3C7DF434: skspwn (spawn.c:420) ==17532== by 0x804E42C: ssa_main_local (init.c:1422) ==17532== by 0x3C7C28C6: ??? (main.c:860) ==17532== by 0x3C7E42E4: ??? (thread.c:651) ==17532== by 0x3C822D26: thread_wrapper (vg_libpthread.c:745) ==17532== by 0xB800F01F: (within /data2/usr/local/lib/valgrind/stage2) -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Doug R. <df...@nl...> - 2004-02-06 12:00:45
|
On Fri, 2004-02-06 at 10:51, Josef Weidendorfer wrote: > On Friday 06 February 2004 10:39, Nicholas Nethercote wrote: > > On Fri, 6 Feb 2004, Doug Rabson wrote: > > > > Fix for bug 73326. It seems that gcc 3.2.2 is generating > > > > negatively-sized scopes and out of order line number information in the > > > > stabs debug info. I wonder if this is the stabs writer rotting now that > > > > dwarf is the default... > > > > > > I've seen both of these with old FreeBSD toolchains, typically with > > > gcc-2.95.3 and binutils-2.11.2. I've attempted to fix the out-of-order > > > line info problems but not yet entirely successfully. > > > > I saw out-of-order line number entries, ages ago, when I first hacked on > > the stabs reader; I think I even added the code that allowed them to be > > handled. This was over 18 months ago; maybe it disappeared in the > > subsequent code edits. > > Just curious... What's wrong with out-of-order line numbers? > If a compiler does optimization, line numbers can be shuffled according to > instruction address order. > Sometimes, with the Intel compiler, I get these out-of-order warnings for line > numbers, too (with DWARF). It isn't the line numbers that get out of order, its the address ranges of the line info blocks that the stabs reader parses. |
|
From: Josef W. <Jos...@gm...> - 2004-02-06 10:51:44
|
On Friday 06 February 2004 10:39, Nicholas Nethercote wrote: > On Fri, 6 Feb 2004, Doug Rabson wrote: > > > Fix for bug 73326. It seems that gcc 3.2.2 is generating > > > negatively-sized scopes and out of order line number information in the > > > stabs debug info. I wonder if this is the stabs writer rotting now that > > > dwarf is the default... > > > > I've seen both of these with old FreeBSD toolchains, typically with > > gcc-2.95.3 and binutils-2.11.2. I've attempted to fix the out-of-order > > line info problems but not yet entirely successfully. > > I saw out-of-order line number entries, ages ago, when I first hacked on > the stabs reader; I think I even added the code that allowed them to be > handled. This was over 18 months ago; maybe it disappeared in the > subsequent code edits. Just curious... What's wrong with out-of-order line numbers? If a compiler does optimization, line numbers can be shuffled according to instruction address order. Sometimes, with the Intel compiler, I get these out-of-order warnings for line numbers, too (with DWARF). Josef |
|
From: Nicholas N. <nj...@ca...> - 2004-02-06 09:40:00
|
On Fri, 6 Feb 2004, Doug Rabson wrote: > > Fix for bug 73326. It seems that gcc 3.2.2 is generating negatively-sized > > scopes and out of order line number information in the stabs debug info. > > I wonder if this is the stabs writer rotting now that dwarf is the > > default... > > I've seen both of these with old FreeBSD toolchains, typically with > gcc-2.95.3 and binutils-2.11.2. I've attempted to fix the out-of-order > line info problems but not yet entirely successfully. I saw out-of-order line number entries, ages ago, when I first hacked on the stabs reader; I think I even added the code that allowed them to be handled. This was over 18 months ago; maybe it disappeared in the subsequent code edits. N |
|
From: Doug R. <df...@nl...> - 2004-02-06 09:20:45
|
On Thu, 2004-02-05 at 22:58, Jeremy Fitzhardinge wrote: > CVS commit by fitzhardinge: > > Fix for bug 73326. It seems that gcc 3.2.2 is generating negatively-sized > scopes and out of order line number information in the stabs debug info. > I wonder if this is the stabs writer rotting now that dwarf is the > default... I've seen both of these with old FreeBSD toolchains, typically with gcc-2.95.3 and binutils-2.11.2. I've attempted to fix the out-of-order line info problems but not yet entirely successfully. |
|
From: Jeremy F. <je...@go...> - 2004-02-05 22:58:44
|
CVS commit by fitzhardinge:
Fix for bug 73326. It seems that gcc 3.2.2 is generating negatively-sized
scopes and out of order line number information in the stabs debug info.
I wonder if this is the stabs writer rotting now that dwarf is the
default...
M +2 -2 vg_symtab2.c 1.75
--- valgrind/coregrind/vg_symtab2.c #1.74:1.75
@@ -302,6 +302,6 @@ void VG_(addScopeInfo) ( SegInfo* si,
ScopeRange range;
- /* Ignore zero-sized scopes */
- if (this == next) {
+ /* Ignore zero-sized or negative scopes */
+ if (size <= 0) {
if (debug)
VG_(printf)("ignoring zero-sized range, scope %p at %p\n", scope, this);
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-05 21:42:46
|
CVS commit by nethercote:
Added VTK, ParaView, Dart and CMaks
M +13 -0 users.html 1.28
--- devel-home/valgrind/users.html #1.27:1.28
@@ -155,4 +155,11 @@
<dd>A visualization tool for brain mapping, dedicated to structural data
browsing.
+
+<dt><a href="http://www.vtk.org">VTK</a>
+<dd>An open source software system for 3D computer graphics, image processing,
+ and visualization.
+
+<dt><a href="http://www.paraview.org">ParaView</a>
+<dd>A visualizer for large data sets.
</dl>
@@ -206,4 +213,10 @@
<dt><a href="http://www.froglogic.com/squish/">Squish</a>
<dd>A cross-platform automated GUI testing framework for Qt/C++ applications.
+
+<dt><a href="http://public.kitware.com/dart/">Dart</a>
+<dd>An open source, distributed, software quality system.
+
+<dt><a href="http://www.cmake.org">CMake</a>
+<dd>A cross-platform, open-source make system.
</dl>
|
|
From: Doug R. <df...@nl...> - 2004-02-05 18:46:50
|
On Thu, 2004-02-05 at 18:27, Jeremy Fitzhardinge wrote: > On Thu, 2004-02-05 at 07:13, Dirk Mueller wrote: > > On Thursday 05 February 2004 14:21, Nicholas Nethercote wrote: > > > > > coregrind/arch/x86 > > > coregrind/arch/x86-freebsd > > > coregrind/arch/x86-linux > > > > IMHO yes, plus the linux-common subdirectory which Jeremy suggested. I was > > waiting for further feedback on the FreeBSD port (as suggested by J) to not > > mess up the CVS repository again when importing it. > > > > if we could finally agree then I can arrange the tree as necessary on the > > server so that we don't loose the commit history. > > Well, I need to give the patch another going over. Then should I send > it to you so you can commit it with all the renames, etc? > > If you do move things around on the server, does that mean we can ever > get back to an older version (ie, with the old layout)? The only way of doing that in CVS is to copy the rcs files to the new locations (renaming any tags, e.g. by prepending 'old') and then using 'cvs rm' to remove the old locations. Subversion is a lot better at this kind of thing - I'm using subversion locally to track my FreeBSD stuff and periodically merge from valgrind cvs. |
|
From: Jeremy F. <je...@go...> - 2004-02-05 18:27:48
|
On Thu, 2004-02-05 at 07:13, Dirk Mueller wrote: > On Thursday 05 February 2004 14:21, Nicholas Nethercote wrote: > > > coregrind/arch/x86 > > coregrind/arch/x86-freebsd > > coregrind/arch/x86-linux > > IMHO yes, plus the linux-common subdirectory which Jeremy suggested. I was > waiting for further feedback on the FreeBSD port (as suggested by J) to not > mess up the CVS repository again when importing it. > > if we could finally agree then I can arrange the tree as necessary on the > server so that we don't loose the commit history. Well, I need to give the patch another going over. Then should I send it to you so you can commit it with all the renames, etc? If you do move things around on the server, does that mean we can ever get back to an older version (ie, with the old layout)? J |
|
From: Jeremy F. <je...@go...> - 2004-02-05 18:26:00
|
On Thu, 2004-02-05 at 07:20, Nicholas Nethercote wrote: > On Thu, 5 Feb 2004, Dirk Mueller wrote: > > > > coregrind/arch/x86 > > > coregrind/arch/x86-freebsd > > > coregrind/arch/x86-linux > > > > IMHO yes, plus the linux-common subdirectory which Jeremy suggested. > > Should that be just 'linux' (to match 'x86')? > > Or should it be 'x86-common' + 'common-linux'? Yes, that's what I was going to do, but use "i386" to match the most common name for the architecture (especially since the AMD64 architecture seems to be most commonly called x86-64, and x86 is a bit close). J |
|
From: Nicholas N. <nj...@ca...> - 2004-02-05 15:20:25
|
On Thu, 5 Feb 2004, Dirk Mueller wrote: > > coregrind/arch/x86 > > coregrind/arch/x86-freebsd > > coregrind/arch/x86-linux > > IMHO yes, plus the linux-common subdirectory which Jeremy suggested. Should that be just 'linux' (to match 'x86')? Or should it be 'x86-common' + 'common-linux'? > if we could finally agree then I can arrange the tree as necessary on the > server so that we don't loose the commit history. Ah, good. N |
|
From: Dirk M. <dm...@gm...> - 2004-02-05 15:13:56
|
On Thursday 05 February 2004 14:21, Nicholas Nethercote wrote: > coregrind/arch/x86 > coregrind/arch/x86-freebsd > coregrind/arch/x86-linux IMHO yes, plus the linux-common subdirectory which Jeremy suggested. I was waiting for further feedback on the FreeBSD port (as suggested by J) to not mess up the CVS repository again when importing it. if we could finally agree then I can arrange the tree as necessary on the server so that we don't loose the commit history. |
|
From: Nicholas N. <nj...@ca...> - 2004-02-05 14:28:00
|
CVS commit by nethercote:
Fix broken "make dist".
Doesn't fix "make distcheck", however, because this happens:
/usr/bin/ld: cannot open linker script file ../../coregrind/x86/stage2.lds:
No such file or directory
For some reason I can't work out, that file is built when you make in a CVS
tree, or manually from a "make dist" tarball, but not when you "make
distcheck".
M +1 -1 Makefile.am 1.66
M +0 -1 x86/Makefile.am 1.5
--- valgrind/coregrind/Makefile.am #1.65:1.66
@@ -1,4 +1,4 @@
-SUBDIRS = x86 demangle . docs
+SUBDIRS = x86 demangle arch . docs
add_includes = -I$(srcdir)/demangle -I$(top_srcdir)/include -I$(srcdir)/x86
--- valgrind/coregrind/x86/Makefile.am #1.4:1.5
@@ -3,5 +3,4 @@
EXTRA_DIST = \
- Make.inc \
ume_archdefs.c \
ume_archdefs.h \
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-05 13:21:39
|
Hi, I'm wondering about the directory structure for arch-specific bits. Currently we have: coregrind/x86 coregrind/arch/ coregrind/arch/x86-freebsd coregrind/arch/x86-linux seems to me like it should be coregrind/arch/x86 coregrind/arch/x86-freebsd coregrind/arch/x86-linux or coregrind/x86 coregrind/x86-freebsd coregrind/x86-linux ? N |
|
From: Nicholas N. <nj...@ca...> - 2004-02-05 09:57:58
|
On Wed, 4 Feb 2004, Julian Seward wrote: > My vote is to add it asap. Does it need the hp2ps Glasgow stuff, or > not? I forget. Yes, I have put it in valgrind/massif/hp2ps. The (BSD-style) LICENSE file is in that directory too, I figure that's enough. I've made a Makefile.am file so it all gets installed properly; the executable goes into $(libdir) along with everything else. Strictly speaking, it should go into $(bindir), but other executables -- stage2, valgrind -- are in $(libdir) too, because the machinery for handling in-place execution makes this option much easier. I've also got it so that Massif automatically invokes hp2ps at the end to convert the raw data to PostScript (well, modulo a small assertion failure that I'm currently working out with Jeremy). So, if all goes well, the user won't need to know anything about hp2ps. N |
|
From: Julian S. <js...@ac...> - 2004-02-04 23:07:19
|
My vote is to add it asap. Does it need the hp2ps Glasgow stuff, or not? I forget. J On Wednesday 04 February 2004 17:48, Nicholas Nethercote wrote: > Hi, > > I'd like to add Massif, my heap-profiling tool (see > www.cl.cam.ac.uk/~njn25/valgrind.html) to the Valgrind repository. > > It seems useful, complements the existing tools well (in that it does > something completely different), is robust, and should be pretty stable. > > I don't know whether it should be added to the actual distributions; > maybe just developer releases, or maybe the stable releases too. But > having it in the repository has two main advantages: > > 1. makes it much easier for people to try it (just check out CVS HEAD) > > 2. saves me from updating it when Valgrind changes > > Another option would be to bundle it up as a separate tool, like Calltree. > That would retain (1) -- in a slightly different way -- but not (2). My > preference would be to put it into CVS, but I don't have compelling > reasons for this. > > Comments? > > N > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@ca...> - 2004-02-04 17:48:44
|
Hi, I'd like to add Massif, my heap-profiling tool (see www.cl.cam.ac.uk/~njn25/valgrind.html) to the Valgrind repository. It seems useful, complements the existing tools well (in that it does something completely different), is robust, and should be pretty stable. I don't know whether it should be added to the actual distributions; maybe just developer releases, or maybe the stable releases too. But having it in the repository has two main advantages: 1. makes it much easier for people to try it (just check out CVS HEAD) 2. saves me from updating it when Valgrind changes Another option would be to bundle it up as a separate tool, like Calltree. That would retain (1) -- in a slightly different way -- but not (2). My preference would be to put it into CVS, but I don't have compelling reasons for this. Comments? N |
|
From: Nicholas N. <nj...@ca...> - 2004-02-04 06:14:16
|
CVS commit by nethercote: Added Opera, Galeon M +6 -0 users.html 1.27 --- devel-home/valgrind/users.html #1.26:1.27 @@ -67,4 +67,10 @@ <dd>A powerful email and newsgroup client derived from the Mozilla suite. +<dt><a href="http://www.opera.com">Opera</a> +<dd>A fast, multi-platform web browser. + +<dt><a href="http://galeon.sf.net">Galeon</a> +<dd>A web browser for GNOME that uses Mozilla's rendering engine. + <dt><a href="http://www.emsoftltd.com/index.php?action=embrowser">Embrowser</a> <dd>A small extensible web browser for internet appliances. |
|
From: Nicholas N. <nj...@ca...> - 2004-02-02 18:23:51
|
CVS commit by nethercote:
Added PostgreSQL
M +3 -0 users.html 1.26
--- devel-home/valgrind/users.html #1.25:1.26
@@ -91,4 +91,7 @@
you</a> from MySQL.)
+<dt><a href="http://www.postgresql.org">PostgreSQL</a>
+<dd>The World's most advanced open source database.
+
<dt><a href="http://www.teratext.com">Teratext Database System</a>
<dd>A terabyte-capable text database.
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-02 17:45:07
|
CVS commit by nethercote: Added the GIMP, MIRA, Anatomist M +1 -1 survey2 1.6 M +10 -0 users.html 1.25 --- devel-home/valgrind/survey2 #1.5:1.6 @@ -34,5 +34,5 @@ comments: -# Any other comments about your first use of Valgrind? +# Any other comments about how you first learnt about Valgrind? --- devel-home/valgrind/users.html #1.24:1.25 @@ -17,4 +17,7 @@ <dd>A commercial multi-platform office productivity suite, based on OpenOffice. +<dt><a href="http://www.gimp.org">The GIMP</a> +<dd>The GNU Image Manipulation Program. + <dt><a href="http://www.lysator.liu.se/~alla/dia/">Dia</a> <dd>A diagram creator, particularly suited to drawing simple circuit diagrams, @@ -136,4 +139,11 @@ <dt><a href="http://www.harmonyware.com">HarmonyWare</a> <dd>NURBS-based geometry translator tools. + +<dt><a href="http://www.chevreux.org/projects_mira.html">MIRA Assembler</a> +<dd>A whole genome shotgun and EST sequence assembler. + +<dt><a href="http://anatomist.info/">Anatomist</a> +<dd>A visualization tool for brain mapping, dedicated to structural data + browsing. </dl> |
|
From: Josef W. <Jos...@gm...> - 2004-02-02 13:36:16
|
Hi, On Sunday 01 February 2004 14:41, Nicholas Nethercote wrote: > The names of the tools are a bit confusing, unfortunately... KCachegrind > doesn't actually read in Cachegrind output. You need Josef Weidendorfer's Yes it does. I kept the format of calltree fully upwards compatible with cachegrind. I think it's quite easy to come up with a patch to support "--dump-instr=yes" in cachegrind. Annotated dissassembled code is always a valuable addition. For the format, insert a line "positions: instr line" at beginning, and pretend each data line with the instruction address relative to the ELF object load address. A little more work would be the need to support this in cg_annotate. But it shouldn't be too hard. Nick, would you accept a patch? Josef > "Calltree" tool, which is based on Cachegrind, but has a different output > format. You can download it from > kcachegrind.sourceforge.net/cgi-bin/show.cgi. > > N |
|
From: Nicholas N. <nj...@ca...> - 2004-02-01 17:30:06
|
CVS commit by nethercote:
Killed the terminally wounded --stop-after option.
M +2 -3 FAQ.txt 1.20
M +0 -1 coregrind/Makefile.am 1.65
M +2 -31 coregrind/vg_include.h 1.179
M +2 -70 coregrind/vg_main.c 1.144
M +1 -30 coregrind/vg_scheduler.c 1.141
M +0 -22 coregrind/vg_translate.c 1.69
M +0 -7 coregrind/docs/coregrind_core.html 1.26
R coregrind/vg_startup.S 1.22
--- valgrind/FAQ.txt #1.19:1.20
@@ -200,7 +200,6 @@
As of 1.9.6, Valgrind only uses these variables with
- --trace-children=no, when executing execve() or using the
- --stop-after=yes flag. This should reduce the potential for
- problems.
+ --trace-children=no or when executing execve(). This should
+ reduce the potential for problems.
-----------------------------------------------------------------
--- valgrind/coregrind/Makefile.am #1.64:1.65
@@ -64,5 +64,4 @@
vg_dummy_profile.c \
vg_signals.c \
- vg_startup.S \
vg_symtab2.c \
vg_dwarf.c \
--- valgrind/coregrind/vg_include.h #1.178:1.179
@@ -244,6 +244,4 @@ extern Bool VG_(clo_trace_sched);
(some), 2 (all) */
extern Int VG_(clo_trace_pthread_level);
-/* Stop after this many basic blocks. default: Infinity. */
-extern ULong VG_(clo_stop_after);
/* Display gory details for the k'th most popular error. default:
Infinity. */
@@ -823,5 +821,5 @@ typedef
Although the segment registers are 16 bits long, storage
- management here, in VG_(baseBlock) and in VG_(m_state_static) is
+ management here and in VG_(baseBlock) is
simplified if we pretend they are 32 bits. */
UInt m_cs;
@@ -911,6 +909,4 @@ typedef
VgSrc_ExitSyscall, /* client called exit(). This is the normal
route out. */
- VgSrc_BbsDone, /* In a debugging run, the specified number of
- bbs has been completed. */
VgSrc_FatalSig /* Killed by the default action of a fatal
signal */
@@ -1337,5 +1333,5 @@ extern Addr VG_(code_redirect) (Addr o
/* Is this a SSE/SSE2-capable CPU? If so, we had better save/restore
the SSE state all over the place. This is set up very early, in
- vg_startup.S. We have to determine it early since we can't even
+ main(). We have to determine it early since we can't even
correctly snapshot the startup machine state without it. */
extern Bool VG_(have_ssestate);
@@ -1373,23 +1369,4 @@ extern Int VG_(clexecfd);
extern const Char *VG_(libdir);
-/* A structure used as an intermediary when passing the simulated
- CPU's state to VG_(switch_to_real_CPU)(), for --stop-after=yes.
- Stuff is copied from baseBlock to here, because it's much easier
- to copy the state into the real registers from this structure than
- the baseBlock, because it's layout is simpler.
- Alignment: the SSE state must be 16-byte aligned. We ask for the whole
- struct to be 16-byte aligned, and the SSE state starts at the 6+8+1+1th
- == 16th word, so it too must be 16-byte aligned. Consequence: change
- this struct only _very carefully_ ! See also above comment re masking
- MXCSR.
-*/
-__attribute__ ((aligned (16)))
-extern UInt VG_(m_state_static) [6 /* segment regs, Intel order */
- + 8 /* int regs, in Intel order */
- + 1 /* %eflags */
- + 1 /* %eip */
- + VG_SIZE_OF_SSESTATE_W /* SSE state */
- ];
-
/* Determine if %esp adjustment must be noted */
extern Bool VG_(need_to_handle_esp_assignment) ( void );
@@ -1644,10 +1621,4 @@ extern Int VG_(clone) ( Int (*fn)(void *
/* ---------------------------------------------------------------------
- Exports of vg_startup.S
- ------------------------------------------------------------------ */
-
-extern void VG_(switch_to_real_CPU) ( void );
-
-/* ---------------------------------------------------------------------
Exports of vg_dispatch.S
------------------------------------------------------------------ */
--- valgrind/coregrind/vg_main.c #1.143:1.144
@@ -164,6 +164,4 @@ UInt VG_(dispatch_ctr);
/* 64-bit counter for the number of basic blocks done. */
ULong VG_(bbs_done);
-/* 64-bit counter for the number of bbs to go before a debug exit. */
-ULong VG_(bbs_to_go);
/* This is the ThreadId of the last thread the scheduler ran. */
@@ -1426,5 +1424,4 @@ Bool VG_(clo_trace_symtab) = False;
Bool VG_(clo_trace_sched) = False;
Int VG_(clo_trace_pthread_level) = 0;
-ULong VG_(clo_stop_after) = 1000000000000000LL;
Int VG_(clo_dump_error) = 0;
Int VG_(clo_backtrace_size) = 4;
@@ -1529,6 +1526,4 @@ void usage ( Bool debug_help )
" --trace-sched=no|yes show thread scheduler details? [no]\n"
" --trace-pthread=none|some|all show pthread event details? [none]\n"
-" --stop-after=<number> switch to real CPU after executing\n"
-" <number> basic blocks [infinity]\n"
" --wait-for-gdb=yes|no pause on startup to wait for gdb attach\n"
"\n"
@@ -1861,7 +1856,4 @@ static void process_cmd_line_options
VG_(clo_lowlat_syscalls) = False;
- else if (VG_CLO_STREQN(13, arg, "--stop-after="))
- VG_(clo_stop_after) = VG_(atoll)(&arg[13]);
-
else if (VG_CLO_STREQN(13, arg, "--dump-error="))
VG_(clo_dump_error) = (Int)VG_(atoll)(&arg[13]);
@@ -2059,6 +2051,4 @@ static void process_cmd_line_options
" as it doesn't generate errors.");
}
-
- VG_(bbs_to_go) = VG_(clo_stop_after);
}
@@ -2099,5 +2089,5 @@ static void setup_file_descriptors(void)
/*====================================================================*/
-/*=== m_state_static + baseBlock: definition, setup, copying ===*/
+/*=== baseBlock: definition + setup ===*/
/*====================================================================*/
@@ -2189,13 +2179,4 @@ Int VG_(noncompact_helper_offsets)[MAX_
UInt VG_(baseBlock)[VG_BASEBLOCK_WORDS];
-/* See comment about this in vg_include.h. Change only with great care. */
-__attribute__ ((aligned (16)))
-UInt VG_(m_state_static) [6 /* segment regs, Intel order */
- + 8 /* int regs, in Intel order */
- + 1 /* %eflags */
- + 1 /* %eip */
- + VG_SIZE_OF_SSESTATE_W /* FPU state */
- ];
-
/* Words. */
static Int baB_off = 0;
@@ -2225,34 +2206,4 @@ Int VG_(extractDflag)(UInt eflags)
}
-static void copy_baseBlock_to_m_state_static( void )
-{
- Int i;
- VG_(m_state_static)[ 0/4] = VG_(baseBlock)[VGOFF_(m_cs)];
- VG_(m_state_static)[ 4/4] = VG_(baseBlock)[VGOFF_(m_ss)];
- VG_(m_state_static)[ 8/4] = VG_(baseBlock)[VGOFF_(m_ds)];
- VG_(m_state_static)[12/4] = VG_(baseBlock)[VGOFF_(m_es)];
- VG_(m_state_static)[16/4] = VG_(baseBlock)[VGOFF_(m_fs)];
- VG_(m_state_static)[20/4] = VG_(baseBlock)[VGOFF_(m_gs)];
-
- VG_(m_state_static)[24/4] = VG_(baseBlock)[VGOFF_(m_eax)];
- VG_(m_state_static)[28/4] = VG_(baseBlock)[VGOFF_(m_ecx)];
- VG_(m_state_static)[32/4] = VG_(baseBlock)[VGOFF_(m_edx)];
- VG_(m_state_static)[36/4] = VG_(baseBlock)[VGOFF_(m_ebx)];
- VG_(m_state_static)[40/4] = VG_(baseBlock)[VGOFF_(m_esp)];
- VG_(m_state_static)[44/4] = VG_(baseBlock)[VGOFF_(m_ebp)];
- VG_(m_state_static)[48/4] = VG_(baseBlock)[VGOFF_(m_esi)];
- VG_(m_state_static)[52/4] = VG_(baseBlock)[VGOFF_(m_edi)];
-
- VG_(m_state_static)[56/4]
- = VG_(insertDflag)(VG_(baseBlock)[VGOFF_(m_eflags)],
- VG_(baseBlock)[VGOFF_(m_dflag)]);
- VG_(m_state_static)[60/4] = VG_(baseBlock)[VGOFF_(m_eip)];
-
- for (i = 0; i < VG_SIZE_OF_SSESTATE_W; i++)
- VG_(m_state_static)[64/4 + i]
- = VG_(baseBlock)[VGOFF_(m_ssestate) + i];
-}
-
-
/* Returns the offset, in words. */
static Int alloc_BaB ( Int words )
@@ -2873,5 +2824,5 @@ int main(int argc, char **argv)
//--------------------------------------------------------------
- // Set up baseBlock, copy machine state (m_state_static)
+ // Set up baseBlock
// p: {pre,post}_clo_init() [for tool helper registration]
// load_client() [for 'client_eip']
@@ -3105,23 +3056,4 @@ int main(int argc, char **argv)
break;
- case VgSrc_BbsDone:
- /* Tricky; we have to try and switch back to the real CPU.
- This is all very dodgy and won't work at all in the
- presence of threads, or if the client happened to be
- running a signal handler. */
- /* Prepare to restore state to the real CPU. */
- VG_(sigshutdown_actions)();
- VG_(load_thread_state)(1 /* root thread */ );
- copy_baseBlock_to_m_state_static();
-
- VG_(proxy_shutdown)();
-
- /* This pushes a return address on the simulator's stack,
- which is abandoned. We call vg_sigshutdown_actions() at
- the end of vg_switch_to_real_CPU(), so as to ensure that
- the original stack and machine state is restored before
- the real signal mechanism is restored. */
- VG_(switch_to_real_CPU)();
-
case VgSrc_FatalSig:
/* We were killed by a fatal signal, so replicate the effect */
--- valgrind/coregrind/vg_scheduler.c #1.140:1.141
@@ -518,5 +518,4 @@ UInt run_thread_for_a_while ( ThreadId t
vg_assert(VG_(is_valid_tid)(tid));
vg_assert(VG_(threads)[tid].status == VgTs_Runnable);
- vg_assert(VG_(bbs_to_go) > 0);
vg_assert(!VG_(scheduler_jmpbuf_valid));
@@ -902,8 +901,4 @@ VgSchedReturnCode VG_(scheduler) ( void
threads but some are blocked on I/O. */
- /* Was a debug-stop requested? */
- if (VG_(bbs_to_go) == 0)
- goto debug_stop;
-
/* Do the following loop until a runnable thread is found, or
deadlock is detected. */
@@ -997,8 +992,5 @@ VgSchedReturnCode VG_(scheduler) ( void
always get at least one decrement even if nothing happens.
*/
- if (VG_(bbs_to_go) >= VG_SCHEDULING_QUANTUM)
VG_(dispatch_ctr) = VG_SCHEDULING_QUANTUM + 1;
- else
- VG_(dispatch_ctr) = (UInt)VG_(bbs_to_go) + 1;
/* ... and remember what we asked for. */
@@ -1187,5 +1179,4 @@ VgSchedReturnCode VG_(scheduler) ( void
done_this_time = (Int)dispatch_ctr_SAVED - (Int)VG_(dispatch_ctr) - 1;
vg_assert(done_this_time >= 0);
- VG_(bbs_to_go) -= (ULong)done_this_time;
VG_(bbs_done) += (ULong)done_this_time;
@@ -1208,7 +1199,4 @@ VgSchedReturnCode VG_(scheduler) ( void
simply by doing nothing, causing us to arrive back at
Phase 1. */
- if (VG_(bbs_to_go) == 0) {
- goto debug_stop;
- }
break;
@@ -1217,7 +1205,4 @@ VgSchedReturnCode VG_(scheduler) ( void
simply by doing nothing, causing us to arrive back at
Phase 1. */
- if (VG_(bbs_to_go) == 0) {
- goto debug_stop;
- }
vg_assert(VG_(dispatch_ctr) == 0);
break;
@@ -1257,18 +1242,4 @@ VgSchedReturnCode VG_(scheduler) ( void
VG_(core_panic)("scheduler: post-main-loop ?!");
/* NOTREACHED */
-
- debug_stop:
- /* If we exited because of a debug stop, print the translation
- of the last block executed -- by translating it again, and
- throwing away the result. */
- VG_(printf)(
- "======vvvvvvvv====== LAST TRANSLATION ======vvvvvvvv======\n");
- VG_(translate)( tid,
- VG_(threads)[tid].m_eip, NULL, NULL, NULL, NULL );
- VG_(printf)("\n");
- VG_(printf)(
- "======^^^^^^^^====== LAST TRANSLATION ======^^^^^^^^======\n");
-
- return VgSrc_BbsDone;
}
--- valgrind/coregrind/vg_translate.c #1.68:1.69
@@ -1510,26 +1510,4 @@ static void vg_improve ( UCodeBlock* cb
FlagSet future_dead_flags;
-# if 0
- /* DEBUGGING HOOK */
- {
- static int n_done=0;
- if (VG_(clo_stop_after) > 1000000000) {
- if (n_done > (VG_(clo_stop_after) - 1000000000)) {
- dis=False;
- VG_(clo_trace_codegen) = 0;
- return;
- }
- if (n_done == (VG_(clo_stop_after) - 1000000000)) {
- VG_(printf)("\n");
- VG_(pp_UCodeBlock) ( cb, "Incoming:" );
- dis = True;
- VG_(clo_trace_codegen) = 31;
- }
- n_done++;
- }
- }
- /* end DEBUGGING HOOK */
-# endif /* 0 */
-
if (dis)
VG_(printf) ("Improvements:\n");
--- valgrind/coregrind/docs/coregrind_core.html #1.25:1.26
@@ -925,11 +925,4 @@
<p>
- <li><code>--stop-after=<number></code>
- [default: infinity, more or less]
- <p>After <number> basic blocks have been executed, shut down
- Valgrind and switch back to running the client on the real CPU.
- </li><br>
- <p>
-
<li><code>--dump-error=<number></code> [default: inactive]
<p>After the program has exited, show gory details of the
|