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
(26) |
2
(35) |
3
(18) |
4
(14) |
|
5
(12) |
6
(13) |
7
(11) |
8
(15) |
9
(8) |
10
(13) |
11
(25) |
|
12
(13) |
13
(24) |
14
(7) |
15
(6) |
16
(8) |
17
(6) |
18
(7) |
|
19
(8) |
20
(7) |
21
(5) |
22
(7) |
23
(6) |
24
(7) |
25
(6) |
|
26
(7) |
27
(7) |
28
(5) |
29
(5) |
30
(5) |
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 23:58:28
|
CVS commit by nethercote:
Arch-abstraction step: renamed "vg_include.h" as "core.h".
A coregrind/core.h 1.1 [GPL (v2+)]
M +1 -1 auxprogs/valgrind-listener.c 1.13
M +1 -1 coregrind/Makefile.am 1.80
M +4 -4 coregrind/gen_toolint.pl 1.4
M +1 -1 coregrind/stage1.c 1.18
M +1 -2 coregrind/ume.c 1.21
M +1 -1 coregrind/vg_default.c 1.24
M +1 -1 coregrind/vg_demangle.c 1.8
M +1 -1 coregrind/vg_dummy_profile.c 1.10
M +1 -1 coregrind/vg_dwarf.c 1.5
M +1 -1 coregrind/vg_errcontext.c 1.59
M +1 -1 coregrind/vg_execontext.c 1.17
M +1 -1 coregrind/vg_from_ucode.c 1.83
M +1 -1 coregrind/vg_hashtable.c 1.10
M +1 -1 coregrind/vg_ldt.c 1.17
M +1 -1 coregrind/vg_libpthread.c 1.162
M +2 -2 coregrind/vg_main.c 1.199
M +1 -1 coregrind/vg_malloc2.c 1.32
M +1 -1 coregrind/vg_memory.c 1.67
M +1 -1 coregrind/vg_messages.c 1.15
M +1 -1 coregrind/vg_mylibc.c 1.86
M +1 -1 coregrind/vg_needs.c 1.19
M +1 -1 coregrind/vg_procselfmaps.c 1.12
M +1 -1 coregrind/vg_proxylwp.c 1.19
M +1 -1 coregrind/vg_scheduler.c 1.172
M +1 -1 coregrind/vg_signals.c 1.82
M +1 -1 coregrind/vg_skiplist.c 1.6
M +1 -1 coregrind/vg_stabs.c 1.15
M +1 -1 coregrind/vg_symtab2.c 1.86
M +1 -1 coregrind/vg_symtypes.c 1.8
M +1 -1 coregrind/vg_syscalls.c 1.133
M +1 -1 coregrind/vg_to_ucode.c 1.147
M +1 -1 coregrind/vg_translate.c 1.89
M +1 -1 coregrind/vg_transtab.c 1.32
M +1 -1 coregrind/demangle/cp-demangle.c 1.7
M +1 -1 coregrind/demangle/cplus-dem.c 1.7
M +1 -1 coregrind/demangle/dyn-string.c 1.6
R coregrind/vg_include.h 1.235
--- valgrind/auxprogs/valgrind-listener.c #1.12:1.13
@@ -47,5 +47,5 @@
/* For VG_CLO_DEFAULT_LOGPORT and VG_BUGS_TO. */
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/Makefile.am #1.79:1.80
@@ -140,7 +140,7 @@
noinst_HEADERS = \
+ core.h \
ume.h \
ume_arch.h \
- vg_include.h \
vg_constants.h \
vg_symtab2.h \
--- valgrind/coregrind/gen_toolint.pl #1.3:1.4
@@ -70,5 +70,5 @@
# Different output modes
if ($output eq "callwrap") {
- $include = "vg_include.h";
+ $include = "core.h";
$generate = sub ($$$@) {
my ($pfx, $ret, $func, @args) = @_;
@@ -80,5 +80,5 @@
}
} elsif ($output eq "proto") {
- $include = "vg_include.h";
+ $include = "core.h";
$generate = sub ($$$@) {
my ($pfx, $ret, $func, @args) = @_;
@@ -96,5 +96,5 @@
}
} elsif ($output eq "missingfuncs") {
- $include = "vg_include.h";
+ $include = "core.h";
$generate = sub ($$$@) {
my ($pfx, $ret, $func, @args) = @_;
@@ -110,5 +110,5 @@
$indent = " ";
} elsif ($output eq "struct") {
- $include = "vg_include.h";
+ $include = "core.h";
$pre = sub () {
print "typedef struct {\n";
--- valgrind/coregrind/stage1.c #1.17:1.18
@@ -41,5 +41,5 @@
#include <sys/resource.h>
-#include "vg_include.h"
+#include "core.h"
#include "ume.h"
--- valgrind/coregrind/ume.c #1.20:1.21
@@ -33,5 +33,5 @@
#define _FILE_OFFSET_BITS 64
-#include "vg_include.h"
+#include "core.h"
#include <stddef.h>
@@ -49,5 +49,4 @@
#include "ume.h"
-#include "vg_include.h"
struct elfinfo
--- valgrind/coregrind/vg_default.c #1.23:1.24
@@ -32,5 +32,5 @@
-#include "vg_include.h"
+#include "core.h"
/* ---------------------------------------------------------------------
--- valgrind/coregrind/vg_demangle.c #1.7:1.8
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include "demangle.h"
--- valgrind/coregrind/vg_dummy_profile.c #1.9:1.10
@@ -31,5 +31,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
static void vgp_die(void)
--- valgrind/coregrind/vg_dwarf.c #1.4:1.5
@@ -28,5 +28,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include "vg_symtab2.h"
--- valgrind/coregrind/vg_errcontext.c #1.58:1.59
@@ -29,5 +29,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
/*------------------------------------------------------------*/
--- valgrind/coregrind/vg_execontext.c #1.16:1.17
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/vg_from_ucode.c #1.82:1.83
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/vg_hashtable.c #1.9:1.10
@@ -29,5 +29,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
/*--------------------------------------------------------------------*/
--- valgrind/coregrind/vg_ldt.c #1.16:1.17
@@ -84,5 +84,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
/* Allocate and deallocate LDTs for threads. */
--- valgrind/coregrind/vg_libpthread.c #1.161:1.162
@@ -54,5 +54,5 @@
#include "valgrind.h" /* For the request-passing mechanism */
-#include "vg_include.h" /* For the VG_USERREQ__* constants */
+#include "core.h" /* For the VG_USERREQ__* constants */
#define __USE_UNIX98
--- valgrind/coregrind/vg_main.c #1.198:1.199
@@ -31,5 +31,5 @@
#define _FILE_OFFSET_BITS 64
-#include "vg_include.h"
+#include "core.h"
#include "ume.h"
#include "ume_arch.h"
@@ -1443,5 +1443,5 @@ Bool VG_(clo_demangle) = True;
Bool VG_(clo_trace_children) = False;
-/* See big comment in vg_include.h for meaning of these three.
+/* See big comment in core.h for meaning of these three.
fd is initially stdout, for --help, but gets moved to stderr by default
immediately afterwards. */
--- valgrind/coregrind/vg_malloc2.c #1.31:1.32
@@ -31,5 +31,5 @@
-#include "vg_include.h"
+#include "core.h"
//#define DEBUG_MALLOC // turn on heavyweight debugging machinery
--- valgrind/coregrind/vg_memory.c #1.66:1.67
@@ -31,5 +31,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include <stddef.h>
--- valgrind/coregrind/vg_messages.c #1.14:1.15
@@ -31,5 +31,5 @@
-#include "vg_include.h"
+#include "core.h"
#include <time.h>
--- valgrind/coregrind/vg_mylibc.c #1.85:1.86
@@ -31,5 +31,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
/* ---------------------------------------------------------------------
--- valgrind/coregrind/vg_needs.c #1.18:1.19
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/vg_procselfmaps.c #1.11:1.12
@@ -31,5 +31,5 @@
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/vg_proxylwp.c #1.18:1.19
@@ -30,5 +30,5 @@
-#include "vg_include.h"
+#include "core.h"
/* We need our own copy of VG_(do_syscall)() to handle a special
--- valgrind/coregrind/vg_scheduler.c #1.171:1.172
@@ -31,5 +31,5 @@
#include "valgrind.h" /* for VG_USERREQ__RUNNING_ON_VALGRIND and
VG_USERREQ__DISCARD_TRANSLATIONS, and others */
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/vg_signals.c #1.81:1.82
@@ -75,5 +75,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include <stddef.h> /* OK, no library dependencies */
--- valgrind/coregrind/vg_skiplist.c #1.5:1.6
@@ -83,5 +83,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include <stdlib.h>
--- valgrind/coregrind/vg_stabs.c #1.14:1.15
@@ -28,5 +28,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include "vg_symtab2.h"
--- valgrind/coregrind/vg_symtab2.c #1.85:1.86
@@ -29,5 +29,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include "vg_symtypes.h"
#include "vg_symtab2.h"
--- valgrind/coregrind/vg_symtypes.c #1.7:1.8
@@ -28,5 +28,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include "vg_symtypes.h"
--- valgrind/coregrind/vg_syscalls.c #1.132:1.133
@@ -29,5 +29,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
/* vg_unsafe.h should NOT be included into any file except this
--- valgrind/coregrind/vg_to_ucode.c #1.146:1.147
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
--- valgrind/coregrind/vg_translate.c #1.88:1.89
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
/*------------------------------------------------------------*/
--- valgrind/coregrind/vg_transtab.c #1.31:1.32
@@ -30,5 +30,5 @@
*/
-#include "vg_include.h"
+#include "core.h"
#include <stddef.h>
--- valgrind/coregrind/demangle/cp-demangle.c #1.6:1.7
@@ -41,5 +41,5 @@
#endif*/
-#include "vg_include.h"
+#include "core.h"
#include "ansidecl.h"
#include "dyn-string.h"
--- valgrind/coregrind/demangle/cplus-dem.c #1.6:1.7
@@ -38,5 +38,5 @@ Boston, MA 02111-1307, USA. */
#include "safe-ctype.h"
-#include "vg_include.h"
+#include "core.h"
/*#include <sys/types.h>
--- valgrind/coregrind/demangle/dyn-string.c #1.5:1.6
@@ -32,5 +32,5 @@ Boston, MA 02111-1307, USA. */
#endif*/
-#include "vg_include.h"
+#include "core.h"
#include "ansidecl.h"
#include "dyn-string.h"
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 23:34:44
|
CVS commit by nethercote: Update .cvsignore for recently added regression tests. M +1 -0 corecheck/tests/.cvsignore 1.7 M +1 -0 memcheck/tests/.cvsignore 1.15 M +2 -1 none/tests/.cvsignore 1.19 --- valgrind/corecheck/tests/.cvsignore #1.6:1.7 @@ -27,4 +27,5 @@ fdleak_socketpair pth_exit +pth_exit2 vgprintf as_shm --- valgrind/memcheck/tests/.cvsignore #1.14:1.15 @@ -56,4 +56,5 @@ badrw brk +brk2 metadata new_nothrow --- valgrind/none/tests/.cvsignore #1.18:1.19 @@ -36,6 +36,7 @@ int map_unmap -munmap_exe +mq mremap +munmap_exe pluto pth_blockedsig |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 23:20:59
|
CVS commit by nethercote:
Use Makefile.am includes. This gets rid of 110 lines of repetitive Makefile.am
cruft, yay!
A Makefile.all.am 1.1
A Makefile.core-AM_CPPFLAGS.am 1.1
A Makefile.tool-inplace.am 1.1
A Makefile.tool.am 1.1
M +6 -9 Makefile.am 1.70
M +2 -13 addrcheck/Makefile.am 1.52
M +3 -6 auxprogs/Makefile.am 1.9
M +1 -13 cachegrind/Makefile.am 1.46
M +1 -13 corecheck/Makefile.am 1.45
M +4 -7 coregrind/Makefile.am 1.79
M +3 -2 coregrind/demangle/Makefile.am 1.13
M +1 -13 helgrind/Makefile.am 1.49
M +1 -14 lackey/Makefile.am 1.46
M +2 -12 massif/Makefile.am 1.5
M +3 -11 massif/hp2ps/Makefile.am 1.5
M +3 -15 memcheck/Makefile.am 1.51
M +1 -13 none/Makefile.am 1.46
--- valgrind/Makefile.am #1.69:1.70
@@ -2,5 +2,7 @@
AUTOMAKE_OPTIONS = foreign 1.6 dist-bzip2
-## include must be first for vg_skin.h
+include $(top_srcdir)/Makefile.all.am
+
+## include must be first for tool.h
## addrcheck must come after memcheck, for mac_*.o
SUBDIRS = include coregrind . docs tests auxprogs \
@@ -14,11 +16,4 @@
none
-AM_CPPFLAGS =
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
-
SUPP_FILES = \
glibc-2.1.supp glibc-2.2.supp glibc-2.3.supp \
@@ -45,5 +40,7 @@
README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
- valgrind.spec.in valgrind.pc.in
+ valgrind.spec.in valgrind.pc.in \
+ Makefile.all.am Makefile.tool.am Makefile.core-AM_CPPFLAGS.am \
+ Makefile.tool-inplace.am
install-exec-hook:
--- valgrind/addrcheck/Makefile.am #1.51:1.52
@@ -1,13 +1,6 @@
-
-SUBDIRS = . docs tests
+include $(top_srcdir)/Makefile.tool.am
# include memcheck/ for mac_shared.h
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
- -I$(top_srcdir)/memcheck
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+AM_CPPFLAGS += -I$(top_srcdir)/memcheck
val_PROGRAMS = vgskin_addrcheck.so vgpreload_addrcheck.so
@@ -29,6 +22,2 @@
vgpreload_addrcheck_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(addprefix $(inplacedir)/,$(val_PROGRAMS))
- ln -f -s $(addprefix $(top_builddir)/$(subdir)/,$(val_PROGRAMS)) $(inplacedir)
--- valgrind/auxprogs/Makefile.am #1.8:1.9
@@ -1,12 +1,9 @@
+include $(top_srcdir)/Makefile.all.am
+include $(top_srcdir)/Makefile.core-AM_CPPFLAGS.am
-SUBDIRS = .
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
- -I$(top_builddir)/coregrind -I$(top_srcdir)/coregrind
AM_CFLAGS = $(WERROR) -Winline -Wall -O -g
bin_PROGRAMS = valgrind-listener
-valgrind_listener_SOURCES = \
- valgrind-listener.c
+valgrind_listener_SOURCES = valgrind-listener.c
--- valgrind/cachegrind/Makefile.am #1.45:1.46
@@ -1,11 +1,3 @@
-
-SUBDIRS = . docs tests
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+include $(top_srcdir)/Makefile.tool.am
bin_SCRIPTS = cg_annotate
@@ -18,6 +10,2 @@
vgskin_cachegrind_so_LDFLAGS = -shared
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(inplacedir)/$(val_PROGRAMS)
- ln -f -s $(top_builddir)/$(subdir)/$(val_PROGRAMS) $(inplacedir)/$(val_PROGRAMS)
--- valgrind/corecheck/Makefile.am #1.44:1.45
@@ -1,11 +1,3 @@
-
-SUBDIRS = . tests docs
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+include $(top_srcdir)/Makefile.tool.am
val_PROGRAMS = vgskin_corecheck.so
@@ -14,6 +6,2 @@
vgskin_corecheck_so_LDFLAGS = -shared
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(inplacedir)/$(val_PROGRAMS)
- ln -f -s $(top_builddir)/$(subdir)/$(val_PROGRAMS) $(inplacedir)/$(val_PROGRAMS)
--- valgrind/coregrind/Makefile.am #1.78:1.79
@@ -1,12 +1,9 @@
+include $(top_srcdir)/Makefile.all.am
+include $(top_srcdir)/Makefile.core-AM_CPPFLAGS.am
SUBDIRS = x86 demangle . docs
-add_includes = -I$(srcdir)/demangle -I$(top_builddir)/include \
- -I$(top_srcdir)/include -I$(srcdir)/x86
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
-
-AM_CPPFLAGS = $(add_includes) -DVG_LIBDIR="\"$(valdir)"\" \
+AM_CPPFLAGS += -DVG_LIBDIR="\"$(valdir)"\" -I$(srcdir)/demangle \
+ -I$(srcdir)/x86 \
-DKICKSTART_BASE=$(KICKSTART_BASE)
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fno-omit-frame-pointer \
--- valgrind/coregrind/demangle/Makefile.am #1.12:1.13
@@ -1,5 +1,5 @@
+include $(top_srcdir)/Makefile.all.am
+include $(top_srcdir)/Makefile.core-AM_CPPFLAGS.am
-AM_CPPFLAGS = -I$(top_builddir)/coregrind -I$(top_srcdir)/coregrind \
- -I$(top_builddir)/include -I$(top_srcdir)/include
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer -g
@@ -15,4 +15,5 @@
cp-demangle.c cplus-dem.c dyn-string.c safe-ctype.c
+## Ignore harmless warnings for these ones
cp-demangle.o: CFLAGS += -Wno-unused -Wno-shadow
cplus-dem.o: CFLAGS += -Wno-unused
--- valgrind/helgrind/Makefile.am #1.48:1.49
@@ -1,11 +1,3 @@
-
-SUBDIRS = . docs tests
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+include $(top_srcdir)/Makefile.tool.am
val_PROGRAMS = vgskin_helgrind.so vgpreload_helgrind.so
@@ -23,6 +15,2 @@
hginclude_HEADERS = helgrind.h
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(addprefix $(inplacedir)/,$(val_PROGRAMS))
- ln -f -s $(addprefix $(top_builddir)/$(subdir)/,$(val_PROGRAMS)) $(inplacedir)
--- valgrind/lackey/Makefile.am #1.45:1.46
@@ -1,11 +1,3 @@
-
-SUBDIRS = . docs tests
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+include $(top_srcdir)/Makefile.tool.am
val_PROGRAMS = vgskin_lackey.so
@@ -14,7 +6,2 @@
vgskin_lackey_so_LDFLAGS = -shared
-
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(inplacedir)/$(val_PROGRAMS)
- ln -f -s $(top_builddir)/$(subdir)/$(val_PROGRAMS) $(inplacedir)/$(val_PROGRAMS)
--- valgrind/massif/Makefile.am #1.4:1.5
@@ -1,11 +1,5 @@
+include $(top_srcdir)/Makefile.tool.am
-SUBDIRS = . tests docs hp2ps
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+SUBDIRS += hp2ps
val_PROGRAMS = vgskin_massif.so vgpreload_massif.so
@@ -19,6 +13,2 @@
vgpreload_massif_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(addprefix $(inplacedir)/,$(val_PROGRAMS))
- ln -f -s $(addprefix $(top_builddir)/$(subdir)/,$(val_PROGRAMS)) $(inplacedir)
--- valgrind/massif/hp2ps/Makefile.am #1.4:1.5
@@ -1,10 +1,5 @@
+include $(top_srcdir)/Makefile.all.am
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
-
-AM_CPPFLAGS = $(add_includes)
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fno-omit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-AM_CCASFLAGS = $(add_includes)
+AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -g
val_PROGRAMS = hp2ps
@@ -60,7 +55,4 @@
Utilities.h
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(addprefix $(inplacedir)/,$(val_PROGRAMS))
- ln -f -s $(addprefix ../$(subdir)/,$(val_PROGRAMS)) $(inplacedir)
+include $(top_srcdir)/Makefile.tool-inplace.am
--- valgrind/memcheck/Makefile.am #1.50:1.51
@@ -1,14 +1,6 @@
+include $(top_srcdir)/Makefile.tool.am
-SUBDIRS = . tests docs
-
-all_includes = -I$(top_builddir)/include -I$(top_srcdir)/include
-
-AM_CPPFLAGS = $(all_includes)
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O2 -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-AM_CCASFLAGS = $(all_includes)
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+## Build Memcheck at a higher optimisation level
+AM_CFLAGS += -O2
val_PROGRAMS = vgskin_memcheck.so vgpreload_memcheck.so
@@ -44,6 +36,2 @@
mac_replace_strmem.o: CFLAGS += -fno-omit-frame-pointer
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(addprefix $(inplacedir)/,$(val_PROGRAMS))
- ln -f -s $(addprefix $(top_builddir)/$(subdir)/,$(val_PROGRAMS)) $(inplacedir)
--- valgrind/none/Makefile.am #1.45:1.46
@@ -1,11 +1,3 @@
-
-SUBDIRS = . docs tests
-
-AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
-AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
- @PREFERRED_STACK_BOUNDARY@ -g
-
-valdir = $(libdir)/valgrind
-inplacedir = $(top_builddir)/.in_place
+include $(top_srcdir)/Makefile.tool.am
val_PROGRAMS = vgskin_none.so
@@ -14,6 +6,2 @@
vgskin_none_so_LDFLAGS = -shared
-all-local:
- mkdir -p $(inplacedir)
- -rm -f $(inplacedir)/$(val_PROGRAMS)
- ln -f -s $(top_builddir)/$(subdir)/$(val_PROGRAMS) $(inplacedir)/$(val_PROGRAMS)
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 22:03:01
|
On Wed, 1 Sep 2004, Julian Seward wrote: > I just looked through www.cl.cam.ac.uk/~njn25/vg-arch.diff. It looks > good to me; carry on, I say. Righto! Thanks for looking. > One comment: I see a lot of places where a struct called "arch" got > introduced: > > tst->sh_eax = val; > becomes > tst->arch.sh_eax = val; > > and I wonder if it would be wiser to call this "guest." than "arch." > in view of the fact that one day we may be in a world where the guest > and host architectures are not the same, in which case plain .arch is > confusing. Is that possible? I volunteer to make emacs do global > search-n-replace if that helps. I sympathise with the reasoning, but until guest != host is actually working (if it ever does), I think calling it "guest" would be confusing. Changing the name later, if necessary, won't be difficult. So I'll stick with "arch". N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 21:48:18
|
On Wed, 1 Sep 2004, Jeremy Fitzhardinge wrote: >> But when Nicholas said "incremental loading", he meant loading >> debug infos for sections/compile units as we need them. >> That's another problem, not completely decorrelated with >> the "I can't map the whole file to read dbg infos". > > Yes, I know, exactly. Er, no, by "incremental loading" I meant loading the debug info for a single section in pieces, rather than requiring one big mmap(). Loading debug info as we need them I would call "lazy" or "on-demand" loading. Sorry if that was unclear. >> Not sure it's worth doing it for now. How many people still use >> stabs (on the platform we support...) ? > > Valgrind's dwarf support is pretty weak compared to the stabs support - > there's nothing there to extract type information. But Helgrind is the only tool that uses the type information, and not many people use Helgrind. > We only need to resort to padding things out either before we gain full > control (constraining ld.so to put things in the right place) I'm surprised that people with non-overcommitting kernels are not having a problem with this step, but are having a problem with the big-bang shadow memory allocation. I would have thought the padding done by stage1 would involve more than 1.5GB worth of maps. >> BTW, now we are speaking of mem layout, I think it is very important >> to keep in mind that it would be great to bootstrap V... > > You mean self-virtualization? That's a goal, but its tricky. PIE should help, though. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 21:44:19
|
On Tue, 31 Aug 2004, Jeremy Fitzhardinge wrote: >> P2. For kernels with "overcommit" mmapping off -- which prevents a process >> from allocating more address space than the available swap space -- you >> need at least 1.5GB of swap for Memcheck to run, because swap must be at >> least as large as any individual segment. (And I think users with ulimit -v >> set suffer the same problem.) >> >> S2. Avoiding this requires not using the big-bang shadow allocation >> method, and that shadow memory instead be done incrementally. (More about >> that below.) > > Does MAP_NORESERVE work? I'm not sure that incremental mmaping is > enough in all circumstances, because you're trying to work around > heuristics the kernel applies to allocations. MAP_NORESERVE simply > tells the kernel that it shouldn't apply any heuristics to this > allocation. > > If you have strict overcommit enabled, then there's no choice but to > have enough swap - it assumes you're going to use every byte you map. I'm not sure if it was clear what I meant by "incremental shadow memory" here. I meant don't do a big-bang mmap (eg. 1.5GB for Memcheck) at the start, rather, only allocate shadow memory chunks as needed (like in 2.0.0). The good thing about this is that shadow memory chunks can be interleaved with other Valgrind memory, giving much more flexibility, so that address space is much less likely to be exhausted. >> ----------------------------------------------------------------------------- >> P3. Machines with small user spaces (eg. 2G:2G machines) cannot run >> Memcheck, because the big shadow memory region covers 0x40000000, which >> is where normal programs want to put their shadow maps. > > Shadow maps? Do you mean something else? Client mapbase? Yes, sorry for the confusion. >> S5. Two possible fixes: >> - make client/shadow-mem/valgrind divisions less rigid >> - incremental debug info reading (but that's impossible for stabs) > > Well, even for stabs there's no need to mmap the whole thing in; if we > just read (or mmaped) chunks at a time and processed them serially, we > can extract everything needed. Hmm, yes, good idea. Anyone want to volunteer? >> The downside of switching to incremental shadow memory is that it makes >> direct-offset shadow addressing impossible, at least on 32-bit. > > The trouble is that memcheck&co do have a fixed ratio of shadow memory > to real memory used. If the client uses its address space sparsely then > it causes sparse (wasteful) use of the shadow memory, Exactly, that's why I'm arguing against direct-offset shadow addressing. > but since we get > to place all the mmaps, we needn't make it have sparse memory use. The > exception is if the client explicitly places its mappings, but I don't > think that's common. > > So I know that people are running into memory problems, but it isn't > clear to me that we can't solve them by using the address space more > densely. (I assume you mean the client portion of the address space?) How do propose to use the client address space more densely? I can't see how this would work. I'm not sure if we're all on the same wavelength with this stuff. > Tools which don't have a fixed ratio (cachegrind) are another issue. > They're not, technically, using shadow memory (since there isn't the 1:1 > relationship between client addresses and shadow addresses), but > Valgrind heap. I'm not sure why you say "technically"; Cachegrind (and Calltree, Nulgrind, and Massif) don't use shadow memory at all. Much of the discussion doesn't apply to them. However, they are still affected by some of the rigidity problems eg. Calltree suffers from Problem P4. (And "valgrind heap" is misleading because Valgrind no longer has a heap as such; I took it out when I rejigged the memory layout stuff. It now only allocates via maps.) >> Only question here is: where does the stack go? If the stack size is >> ulimited (eg. to 8MB), there's little problem. Otherwise, perhaps >> below client_mapbase, so it grows down towards the upward-growing >> heap. [nb: what happens if they collide? undefined?] > > We could put the stack below the executable. The x86 ABI allows this > (and Solaris x86 does this). It could break some programs which assume > the stack is high, but most won't care. A problem with that is that on x86-64 executables are mapped very low, 0x400000 I think (4MB), which doesn't leave enough room for even an 8MB stack. I like the idea of putting it just below client_mapbase better. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 21:21:33
|
On Wed, 1 Sep 2004, Eric Estievenart wrote: >> The downside of switching to incremental shadow memory is that it makes >> direct-offset shadow addressing impossible, at least on 32-bit. > > I wouldn't be so categoric. We can certainly do a big-bang _reservation_ > (not allocation), using either MAP_NORESERVE or shm mappings, and > incrementally remap parts as we need them. Sure, but then you still have taken a great big chunk out of the address space for shadow memory (irrespective whether you've allocated it or not) and that still causes all the problems whereby the layout is too rigid. N |
|
From: Jeremy F. <je...@go...> - 2004-09-01 20:46:51
|
On Wed, 2004-09-01 at 20:00 +0200, Eric Estievenart wrote: > > Well, even for stabs there's no need to mmap the whole thing in; if we > > just read (or mmaped) chunks at a time and processed them serially, we > > can extract everything needed. > > Indeed, there is always a solution. But we have to store indices > to the .stabstr section and try to read it sequentially (or map it > chunks by chunks, or whatever) because it is a random-access section. That should be reasonably easy to manage (depends on how big the strings are compared to everything else). > But when Nicholas said "incremental loading", he meant loading > debug infos for sections/compile units as we need them. > That's another problem, not completely decorrelated with > the "I can't map the whole file to read dbg infos". Yes, I know, exactly. > Not sure it's worth doing it for now. How many people still use > stabs (on the platform we support...) ? Valgrind's dwarf support is pretty weak compared to the stabs support - there's nothing there to extract type information. > Client seldom places its mappings, but we must _reserve_ areas, > otherwise the kernel may decide to place a client mapping in an > area which will bother us after... Only occasionally. We explicitly place all the mappings the client makes with mmap, for example. We only need to resort to padding things out either before we gain full control (constraining ld.so to put things in the right place), or for stupid syscall which create mappings without asking where (the async IO thing). > BTW, now we are speaking of mem layout, I think it is very important > to keep in mind that it would be great to bootstrap V... You mean self-virtualization? That's a goal, but its tricky. J |
|
From: Eric E. <eri...@fr...> - 2004-09-01 18:00:28
|
Jeremy Fitzhardinge wrote: > Does MAP_NORESERVE work? I'm not sure that incremental mmaping is > enough in all circumstances, because you're trying to work around > heuristics the kernel applies to allocations. MAP_NORESERVE simply > tells the kernel that it shouldn't apply any heuristics to this > allocation. FYI, I've tried reserving all the memory space with MAP_NORESERVE, and no swap (swapoff'd before testing). This on a normal 3G:1G 2.6 kernel. With that, I'm able to reserve 2G in memory, in the range 0x40000000 to 0xC0000000. Strangely mmap( NULL, ... MAP_NORESERVE ) will never return a zone in the 0-0x40000000 range, even if there is no other free ranges... To reserve the free chunks of that area, many shmat work, but you are not sure you will have reserved everything except if you scan /proc/self/maps or if you use a dichotomic heuristic to try to grab everything. The documentation (linux/Documentation/vm/overcommit-accounting) says (I summarize here): 3 modes: 0 - Heuristic handling; refuses obvious overcommits (default) 1 - No overcommit handling 2 - New strict overcommit. Commit space must be < swap + percentage of ram set through vm.overcommit_memory sysctl or /proc/sys/vm/overcommit_(memory|ratio). > In mode 2 the MAP_NORESERVE flag is ignored. Ooops we (may) have a problem.... but: > The overcommit is based on the following rules: > For an anonymous or /dev/zero map > SHARED - size of mapping > PRIVATE READ-only - 0 cost (but of little use) Maybe of little use, but it is exactly what we need :-) So I performed the tests, with the 3 types of overcommit, and PROT_NONE and MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE .... > If you have strict overcommit enabled, then there's no choice but to > have enough swap - it assumes you're going to use every byte you map. [trumpets] It worked !!!! I reserved the 3G of usable addressing space (2G with the mmap, the remaining 1G with a repeated shm mapping), all that with less than 500M of memory available... > Well, even for stabs there's no need to mmap the whole thing in; if we > just read (or mmaped) chunks at a time and processed them serially, we > can extract everything needed. Indeed, there is always a solution. But we have to store indices to the .stabstr section and try to read it sequentially (or map it chunks by chunks, or whatever) because it is a random-access section. But when Nicholas said "incremental loading", he meant loading debug infos for sections/compile units as we need them. That's another problem, not completely decorrelated with the "I can't map the whole file to read dbg infos". Not sure it's worth doing it for now. How many people still use stabs (on the platform we support...) ? > The trouble is that memcheck&co do have a fixed ratio of shadow memory > to real memory used. If the client uses its address space sparsely then > it causes sparse (wasteful) use of the shadow memory, but since we get > to place all the mmaps, we needn't make it have sparse memory use. The > exception is if the client explicitly places its mappings, but I don't > think that's common. Client seldom places its mappings, but we must _reserve_ areas, otherwise the kernel may decide to place a client mapping in an area which will bother us after... BTW, now we are speaking of mem layout, I think it is very important to keep in mind that it would be great to bootstrap V... Cheers ;-) -- Eric |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 11:33:49
|
CVS commit by nethercote:
'valgrind' (ie. stage1) does not need to be installed in $PREFIX/lib/valgrind/;
$PREFIX/bin/ is enough.
M +1 -1 Makefile.am 1.78
--- valgrind/coregrind/Makefile.am #1.77:1.78
@@ -20,5 +20,5 @@
val_PROGRAMS = \
- valgrind stage2 \
+ stage2 \
libpthread.so \
vg_inject.so
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 11:28:00
|
On Wed, 1 Sep 2004, Paul Mackerras wrote: > I have packaged up a version of my PPC port that corresponds to the > 2.2.0 release of Valgrind. The tarball is at: > > http://ozlabs.org/~paulus/valgrind-2.2.0-ppc.tar.bz2 > > Could someone please update the web pages at valgrind.kde.org in the > places where my PPC port is mentioned to point to the new tarball? > On the `Related Projects' page, the dot point about not supporting > Altivec instructions is no longer true, so please remove that. Done. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 11:27:15
|
CVS commit by nethercote: Update info about Paul's PPC port. M +3 -5 related.html 1.18 --- devel-home/valgrind/related.html #1.17:1.18 @@ -83,6 +83,6 @@ <h3>Ports to Other Architectures</h3> -Paul Mackerras has an experimental port of Valgrind 2.1.0 to PowerPC/Linux -(<a href="http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2">download</a>). +Paul Mackerras has an experimental port of Valgrind 2.2.0 to PowerPC/Linux +(<a href="http://ozlabs.org/~paulus/valgrind-2.2.0-ppc.tar.bz2">download</a>). <p> Some caveats: @@ -90,10 +90,8 @@ <li>It only supports 32-bit instructions at present (no 64-bit instructions). <p> -<li>It doesn't handle Altivec (SIMD) instructions. - <p> <li>There are no PowerPC-specific suppression files yet, so libc.so and ld.so cause a lot of errors. <p> -<li>The code to set cache parameters in cachegrind is pretty minimal at +<li>The code to set cache parameters in Cachegrind is pretty minimal at present. <p> |
|
From: Ashley P. <as...@qu...> - 2004-09-01 09:55:09
|
On Tue, 2004-08-31 at 23:50, Nicholas Nethercote wrote: > The downside of switching to incremental shadow memory is that it makes > direct-offset shadow addressing impossible, at least on 32-bit. > Direct-offset seems much more plausible on 64-bit, where we have more > address to play with. But the benefits of direct-offset still are not > clear (Jeremy's experiments didn't show a speed improvement), and we don't > have any 64-bit ports working yet. Somewhat of an aside as these problems all need to be fixed for 32bit systems anyway but 64bit doesn't give you the address space freedom you might expect, at least one arch is limited to three virtual address space regions of one terabyte each. Ashley, |
|
From: Julian S. <js...@ac...> - 2004-09-01 09:32:34
|
> >> www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 > > > > Looks good, but you seem to have left out Makefile.all.am, > > Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. > > > > The rest of your proposal looks fine to me. > > Does anyone else have any comments about/objections to my proposal? I'd > like to start moving it in. I just looked through www.cl.cam.ac.uk/~njn25/vg-arch.diff. It looks good to me; carry on, I say. One comment: I see a lot of places where a struct called "arch" got introduced: tst->sh_eax = val; becomes tst->arch.sh_eax = val; and I wonder if it would be wiser to call this "guest." than "arch." in view of the fact that one day we may be in a world where the guest and host architectures are not the same, in which case plain .arch is confusing. Is that possible? I volunteer to make emacs do global search-n-replace if that helps. J |
|
From: Tom H. <th...@cy...> - 2004-09-01 08:49:24
|
In message <1094008711.3129.27.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2004-08-31 at 23:50 +0100, Nicholas Nethercote wrote:
>> P2. For kernels with "overcommit" mmapping off -- which prevents a process
>> from allocating more address space than the available swap space -- you
>> need at least 1.5GB of swap for Memcheck to run, because swap must be at
>> least as large as any individual segment. (And I think users with ulimit -v
>> set suffer the same problem.)
>>
>> S2. Avoiding this requires not using the big-bang shadow allocation
>> method, and that shadow memory instead be done incrementally. (More about
>> that below.)
>
> Does MAP_NORESERVE work? I'm not sure that incremental mmaping is
> enough in all circumstances, because you're trying to work around
> heuristics the kernel applies to allocations. MAP_NORESERVE simply
> tells the kernel that it shouldn't apply any heuristics to this
> allocation.
>
> If you have strict overcommit enabled, then there's no choice but to
> have enough swap - it assumes you're going to use every byte you map.
I haven't looked to see what the kernel actually does, but the manual
page claims (and it may well be wrong) that MAP_NORESERVE explicitly
prevents pre-allocation of swap space for the mapping:
MAP_NORESERVE
(Used together with MAP_PRIVATE.) Do not reserve swap space
pages for this mapping. When swap space is reserved, one has the
guarantee that it is possible to modify this private copy-on-
write region. When it is not reserved one might get SIGSEGV
upon a write when no memory is available.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-09-01 08:36:08
|
On Tue, 2004-08-31 at 23:50 +0100, Nicholas Nethercote wrote: > P2. For kernels with "overcommit" mmapping off -- which prevents a process > from allocating more address space than the available swap space -- you > need at least 1.5GB of swap for Memcheck to run, because swap must be at > least as large as any individual segment. (And I think users with ulimit -v > set suffer the same problem.) > > S2. Avoiding this requires not using the big-bang shadow allocation > method, and that shadow memory instead be done incrementally. (More about > that below.) Does MAP_NORESERVE work? I'm not sure that incremental mmaping is enough in all circumstances, because you're trying to work around heuristics the kernel applies to allocations. MAP_NORESERVE simply tells the kernel that it shouldn't apply any heuristics to this allocation. If you have strict overcommit enabled, then there's no choice but to have enough swap - it assumes you're going to use every byte you map. > ----------------------------------------------------------------------------- > P3. Machines with small user spaces (eg. 2G:2G machines) cannot run > Memcheck, because the big shadow memory region covers 0x40000000, which > is where normal programs want to put their shadow maps. Shadow maps? Do you mean something else? Client mapbase? We can put that somewhere else (put it high, and allocate mappings growing down, for example). > S3. Fixing this requires that the boundary between client and Valgrind > is not fixed, which requires incremental shadow memory allocation. > > ----------------------------------------------------------------------------- > P4. Tools sometimes run out of address space when there is still address > space in other regions free. > > S4. The rigidity of the client/shadow-mem/valgrind division must be > reduced to fix this. > > ----------------------------------------------------------------------------- > P5. Large executables (eg. 200MB+) cannot be loaded in memory by > Valgrind in order to read their debug info. > > S5. Two possible fixes: > - make client/shadow-mem/valgrind divisions less rigid > - incremental debug info reading (but that's impossible for stabs) Well, even for stabs there's no need to mmap the whole thing in; if we just read (or mmaped) chunks at a time and processed them serially, we can extract everything needed. > ----------------------------------------------------------------------------- > Discussion > ----------------------------------------------------------------------------- > P1 can be solved independently of the others, and uncontroversially. > > P2--P5 are all related. For 32-bit machines, big-bang shadow memory > allocation does not seem appropriate -- the size of the map required > causes P2. The resulting rigidity of the address space causes P3--P5. > > The downside of switching to incremental shadow memory is that it makes > direct-offset shadow addressing impossible, at least on 32-bit. > Direct-offset seems much more plausible on 64-bit, where we have more > address to play with. But the benefits of direct-offset still are not > clear (Jeremy's experiments didn't show a speed improvement), and we don't > have any 64-bit ports working yet. The trouble is that memcheck&co do have a fixed ratio of shadow memory to real memory used. If the client uses its address space sparsely then it causes sparse (wasteful) use of the shadow memory, but since we get to place all the mmaps, we needn't make it have sparse memory use. The exception is if the client explicitly places its mappings, but I don't think that's common. So I know that people are running into memory problems, but it isn't clear to me that we can't solve them by using the address space more densely. Tools which don't have a fixed ratio (cachegrind) are another issue. They're not, technically, using shadow memory (since there isn't the 1:1 relationship between client addresses and shadow addresses), but Valgrind heap. > > ----------------------------------------------------------------------------- > Solution > ----------------------------------------------------------------------------- > A couple of steps: > > - Don't use big-bang allocation for shadow memory. Make shadow memory > maps allocated just like any other Valgrind/tool memory. Thus > Valgrind would have a single region for itself, instead of two > separate ones. This would solve P2, P4 and P5. > > - Make the client/valgrind division movable. Client memory would grow > up, Valgrind memory would grow down. This would largely solve P3. > > Only question here is: where does the stack go? If the stack size is > ulimited (eg. to 8MB), there's little problem. Otherwise, perhaps > below client_mapbase, so it grows down towards the upward-growing > heap. [nb: what happens if they collide? undefined?] We could put the stack below the executable. The x86 ABI allows this (and Solaris x86 does this). It could break some programs which assume the stack is high, but most won't care. J |
|
From: Tom H. <th...@cy...> - 2004-09-01 07:31:22
|
CVS commit by thughes: Move the include of linux/fs.h before the include of sys/un.h as the latter includes string.h on some older systems which then causes problems when linux/fs.h includes linux/string.h due to it turning various string functions into pre-processor macros. This was the problem behind bug #87820 which actually had nothing to do with gcc 2.95 and everything to do with the glibc and kernel headers that the system had installed. M +1 -1 vg_unsafe.h 1.34 --- valgrind/coregrind/vg_unsafe.h #1.33:1.34 @@ -42,4 +42,5 @@ #define _LINUX_TIME_H #endif +#include <linux/fs.h> /* for filing system ioctls */ #include <linux/net.h> /* for the SYS_* constants */ #include <sys/resource.h> /* for struct rlimit */ @@ -66,5 +67,4 @@ #include <linux/hdreg.h> /* for hard drive ioctls */ #include <linux/netlink.h>/* Some systems need this for linux/fs.h */ -#include <linux/fs.h> /* for filing system ioctls */ #ifdef HAVE_LINUX_FB_H #include <linux/fb.h> /* for fb_* structs */ |
|
From: Tom H. <th...@cy...> - 2004-09-01 07:29:14
|
CVS commit by thughes:
Make some of the parallel port ioctls conditional as older systems
don't have them defined.
M +20 -0 vg_syscalls.c 1.132
--- valgrind/coregrind/vg_syscalls.c #1.131:1.132
@@ -3411,28 +3411,38 @@ PRE(ioctl)
sizeof(int) );
break;
+#ifdef PPGETMODE
case PPGETMODE:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETMODE)", arg3,
sizeof(int) );
break;
+#endif
case PPSETPHASE:
SYSCALL_TRACK( pre_mem_read, tid, "ioctl(PPSETPHASE)", arg3,
sizeof(int) );
break;
+#ifdef PPGETPHASE
case PPGETPHASE:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETPHASE)", arg3,
sizeof(int) );
break;
+#endif
+#ifdef PPGETMODES
case PPGETMODES:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETMODES)", arg3,
sizeof(unsigned int) );
break;
+#endif
+#ifdef PPSETFLAGS
case PPSETFLAGS:
SYSCALL_TRACK( pre_mem_read, tid, "ioctl(PPSETFLAGS)", arg3,
sizeof(int) );
break;
+#endif
+#ifdef PPGETFLAGS
case PPGETFLAGS:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETFLAGS)", arg3,
sizeof(int) );
break;
+#endif
case PPRSTATUS:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPRSTATUS)", arg3,
@@ -3929,5 +3939,7 @@ POST(ioctl)
case PPSETMODE:
case PPSETPHASE:
+#ifdef PPSETFLAGS
case PPSETFLAGS:
+#endif
case PPWDATA:
case PPWCONTROL:
@@ -3938,16 +3950,24 @@ POST(ioctl)
case PPSETTIME:
break;
+#ifdef PPGETMODE
case PPGETMODE:
VG_TRACK( post_mem_write, arg3, sizeof(int) );
break;
+#endif
+#ifdef PPGETPHASE
case PPGETPHASE:
VG_TRACK( post_mem_write, arg3, sizeof(int) );
break;
+#endif
+#ifdef PPGETMODES
case PPGETMODES:
VG_TRACK( post_mem_write, arg3, sizeof(unsigned int) );
break;
+#endif
+#ifdef PPGETFLAGS
case PPGETFLAGS:
VG_TRACK( post_mem_write, arg3, sizeof(int) );
break;
+#endif
case PPRSTATUS:
VG_TRACK( post_mem_write, arg3, sizeof(unsigned char) );
|
|
From: Paul M. <pa...@sa...> - 2004-09-01 04:13:04
|
I have packaged up a version of my PPC port that corresponds to the 2.2.0 release of Valgrind. The tarball is at: http://ozlabs.org/~paulus/valgrind-2.2.0-ppc.tar.bz2 Could someone please update the web pages at valgrind.kde.org in the places where my PPC port is mentioned to point to the new tarball? On the `Related Projects' page, the dot point about not supporting Altivec instructions is no longer true, so please remove that. Thanks, Paul. |
|
From: Tom H. <th...@cy...> - 2004-09-01 03:14:19
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-09-01 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic insn_cmov: valgrind -q ./../../none/tests/insn_cmov insn_fpu: valgrind -q ./../../none/tests/insn_fpu insn_mmx: valgrind -q ./../../none/tests/insn_mmx insn_mmxext: valgrind -q ./../../none/tests/insn_mmxext insn_sse: valgrind -q ./../../none/tests/insn_sse malloc1: valgrind -q ./malloc1 malloc2: valgrind -q ./malloc2 Could not read `malloc2.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-09-01 02:56:03
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-09-01 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-09-01 02:25:17
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-09-01 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-01 02:20:57
|
Nightly build on audi ( Red Hat 9 ) started at 2004-09-01 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-01 02:13:29
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-09-01 03:10:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-01 02:08:18
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-09-01 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |