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
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Tom H. <th...@cy...> - 2004-08-31 02:08:25
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-31 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 |
|
From: Paul M. <pa...@sa...> - 2004-08-31 01:22:06
|
I have Valgrind working on x86 (and on PPC) using a PIE (position
independent executable) for stage2. I'm not suggesting this for the
release, of course.
This patch adds a configure test for PIE support as suggested by Tom
Hughes. With this patch we compile stage2 as a PIE if we can,
otherwise as a normal executable linked at KICKSTART_BASE. It also
makes a library from vg_replace_malloc.o, which means that we can now
specify the CFLAGS for it correctly (i.e., with -fpic).
We currently compile most of the C files that go into the various
shared libraries without -fpic, which means we end up with text
relocations, which is unfortunate. We really should be using -fpic
for them.
Paul.
diff -urN valgrind-cvs/addrcheck/Makefile.am valgrind-x86/addrcheck/Makefile.am
--- valgrind-cvs/addrcheck/Makefile.am 2004-08-24 18:26:20.000000000 +1000
+++ valgrind-x86/addrcheck/Makefile.am 2004-08-31 09:52:53.209339112 +1000
@@ -21,10 +21,10 @@
vgpreload_addrcheck_so_SOURCES =
vgpreload_addrcheck_so_LDADD = \
- $(top_builddir)/coregrind/vg_replace_malloc.o \
+ $(top_builddir)/coregrind/lib_replace_malloc.a \
../memcheck/mac_replace_strmem.o
vgpreload_addrcheck_so_DEPENDENCIES = \
- $(top_builddir)/coregrind/vg_replace_malloc.o \
+ $(top_builddir)/coregrind/lib_replace_malloc.a \
../memcheck/mac_replace_strmem.o
vgpreload_addrcheck_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst
diff -urN valgrind-cvs/configure.in valgrind-x86/configure.in
--- valgrind-cvs/configure.in 2004-08-31 07:57:24.806422384 +1000
+++ valgrind-x86/configure.in 2004-08-31 09:54:01.322368448 +1000
@@ -354,6 +354,22 @@
AC_SUBST(PREFERRED_STACK_BOUNDARY)
+# Check for PIE support in the compiler and linker
+AC_CACHE_CHECK([for PIE support], vg_cv_pie,
+ [safe_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS -fpie"
+ safe_LDFLAGS=$LDFLAGS
+ LDFLAGS="$LDFLAGS -pie"
+ AC_TRY_LINK([int foo;],
+ [],
+ [vg_cv_pie=yes],
+ [vg_cv_pie=no])
+ CFLAGS=$safe_CFLAGS
+ LDFLAGS=$safe_LDFLAGS])
+if test "$vg_cv_pie" = yes; then
+AC_DEFINE([HAVE_PIE], 1, [can create position-independent executables])
+fi
+AM_CONDITIONAL(USE_PIE, test "$vg_cv_pie" = "yes")
# Checks for header files.
diff -urN valgrind-cvs/coregrind/Makefile.am valgrind-x86/coregrind/Makefile.am
--- valgrind-cvs/coregrind/Makefile.am 2004-08-26 08:49:07.000000000 +1000
+++ valgrind-x86/coregrind/Makefile.am 2004-08-31 10:26:30.000000000 +1000
@@ -26,8 +26,7 @@
EXTRA_DIST = \
vg_libpthread.vs valgrind.vs \
gen_toolint.pl toolfuncs.def \
- gen_intercepts.pl vg_replace_malloc.c.base vg_intercept.c.base \
- vg_replace_malloc.c
+ gen_intercepts.pl vg_replace_malloc.c.base vg_intercept.c.base
BUILT_SOURCES = vg_toolint.c vg_toolint.h
CLEANFILES = vg_toolint.c vg_toolint.h vg_replace_malloc.c vg_intercept.c
@@ -85,11 +84,18 @@
vg_transtab.c \
vg_ldt.c \
vg_cpuid.S
-stage2_DEPENDENCIES = $(srcdir)/valgrind.vs x86/stage2.lds
+stage2_DEPENDENCIES = $(srcdir)/valgrind.vs
stage2_LDFLAGS=-Wl,--export-dynamic -Wl,-e,_ume_entry -g \
- -Wl,-defsym,kickstart_base=$(KICKSTART_BASE) \
- -Wl,-T,x86/stage2.lds \
- -Wl,-version-script $(srcdir)/valgrind.vs
+ -Wl,-version-script $(srcdir)/valgrind.vs
+if USE_PIE
+stage2_CFLAGS = $(AM_CFLAGS) -fpie
+stage2_LDFLAGS += -pie
+else
+stage2_CFLAGS = $(AM_CFLAGS)
+stage2_DEPENDENCIES += x86/stage2.lds
+stage2_LDFLAGS += -Wl,-defsym,kickstart_base=$(KICKSTART_BASE) \
+ -Wl,-T,x86/stage2.lds
+endif
stage2_LDADD= \
demangle/cp-demangle.o \
demangle/cplus-dem.o \
@@ -122,9 +128,10 @@
vg_libpthread.c \
vg_libpthread_unimp.c \
vg_syscall.S
+libpthread_so_CFLAGS= $(AM_CFLAGS) -fpic
libpthread_so_DEPENDENCIES = $(srcdir)/vg_libpthread.vs
libpthread_so_LDFLAGS = -Werror -fno-omit-frame-pointer -UVG_LIBDIR \
- -shared -fpic -ldl \
+ -shared -ldl \
-Wl,-version-script $(srcdir)/vg_libpthread.vs \
-Wl,-z,nodelete \
-Wl,--soname=libpthread.so.0
@@ -132,15 +139,15 @@
vg_inject_so_SOURCES = \
vg_intercept.c
-# Not really true, but we need to build vg_replace_malloc.o somehow
-vg_inject_so_DEPENDENCIES = \
- vg_replace_malloc.o
-
+vg_inject_so_CFLAGS = $(AM_CFLAGS) -fpic
vg_inject_so_LDFLAGS = \
-shared \
-Wl,--soname,vg_inject.so \
-Wl,-z,initfirst
+lib_replace_malloc_a_SOURCES = vg_replace_malloc.c
+lib_replace_malloc_a_CFLAGS = $(AM_CFLAGS) -fpic
+
noinst_HEADERS = \
ume.h \
ume_arch.h \
@@ -152,9 +159,9 @@
vg_toolint.h \
vg_unsafe.h
-MANUAL_DEPS = $(noinst_HEADERS) $(include_HEADERS) $(inplacedir)/libpthread.so.0
+noinst_LIBRARIES = lib_replace_malloc.a
-vg_replace_malloc.o vg_intercept.o vg_libpthread.o: CFLAGS += -fno-omit-frame-pointer -g -fpic
+MANUAL_DEPS = $(noinst_HEADERS) $(include_HEADERS) $(inplacedir)/libpthread.so.0
all-local:
mkdir -p $(inplacedir)
diff -urN valgrind-cvs/coregrind/demangle/Makefile.am valgrind-x86/coregrind/demangle/Makefile.am
--- valgrind-cvs/coregrind/demangle/Makefile.am 2004-07-04 21:41:39.000000000 +1000
+++ valgrind-x86/coregrind/demangle/Makefile.am 2004-08-31 09:58:41.068444992 +1000
@@ -1,7 +1,10 @@
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
+AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -g
+if USE_PIE
+AM_CFLAGS += -fpie
+endif
noinst_HEADERS = \
ansidecl.h \
diff -urN valgrind-cvs/coregrind/stage1.c valgrind-x86/coregrind/stage1.c
--- valgrind-cvs/coregrind/stage1.c 2004-08-26 08:49:07.000000000 +1000
+++ valgrind-x86/coregrind/stage1.c 2004-08-31 10:12:11.000000000 +1000
@@ -171,16 +171,24 @@
int *esp;
char buf[strlen(valgrind_lib) + sizeof(stage2) + 16];
- info.exe_base = PGROUNDUP(&_end);
info.exe_end = PGROUNDDN(ume_exec_esp);
+#ifdef HAVE_PIE
+ info.exe_base = ROUNDDN(info.exe_end - 0x02000000, 0x10000000);
+ assert(info.exe_base >= PGROUNDUP(&_end));
+ info.map_base = info.exe_base + 0x01000000;
+
+#else
/* XXX FIXME: how can stage1 know where stage2 wants things placed?
Options:
- we could look for a symbol
- it could have a special PHDR (v. ELF specific)
- something else?
*/
+ info.exe_base = PGROUNDUP(&_end);
info.map_base = KICKSTART_BASE + 0x01000000;
+#endif
+
info.argv = NULL;
snprintf(buf, sizeof(buf), "%s/%s", valgrind_lib, stage2);
diff -urN valgrind-cvs/coregrind/ume.c valgrind-x86/coregrind/ume.c
--- valgrind-cvs/coregrind/ume.c 2004-08-11 09:37:54.000000000 +1000
+++ valgrind-x86/coregrind/ume.c 2004-08-31 10:00:07.639329384 +1000
@@ -416,6 +416,11 @@
ESZ(Word) interp_size = 0;
int i;
void *entry;
+ ESZ(Addr) ebase = 0;
+
+#ifdef HAVE_PIE
+ ebase = info->exe_base;
+#endif
e = readelf(fd, name);
@@ -423,14 +428,14 @@
return ENOEXEC;
info->phnum = e->e.e_phnum;
- info->entry = e->e.e_entry;
+ info->entry = e->e.e_entry + ebase;
for(i = 0; i < e->e.e_phnum; i++) {
ESZ(Phdr) *ph = &e->p[i];
switch(ph->p_type) {
case PT_PHDR:
- info->phdr = ph->p_vaddr;
+ info->phdr = ph->p_vaddr + ebase;
break;
case PT_LOAD:
@@ -489,8 +494,8 @@
if (info->exe_base != info->exe_end) {
if (minaddr >= maxaddr ||
- (minaddr < info->exe_base ||
- maxaddr > info->exe_end)) {
+ (minaddr + ebase < info->exe_base ||
+ maxaddr + ebase > info->exe_end)) {
fprintf(stderr, "Executable range %p-%p is outside the\n"
"acceptable range %p-%p\n",
(void *)minaddr, (void *)maxaddr,
@@ -499,7 +504,7 @@
}
}
- info->brkbase = mapelf(e, 0); /* map the executable */
+ info->brkbase = mapelf(e, ebase); /* map the executable */
if (info->brkbase == 0)
return ENOMEM;
@@ -532,8 +537,8 @@
} else
entry = (void *)e->e.e_entry;
- info->exe_base = minaddr;
- info->exe_end = maxaddr;
+ info->exe_base = minaddr + ebase;
+ info->exe_end = maxaddr + ebase;
info->init_eip = (addr_t)entry;
diff -urN valgrind-cvs/coregrind/vg_main.c valgrind-x86/coregrind/vg_main.c
--- valgrind-cvs/coregrind/vg_main.c 2004-08-31 07:57:55.252454392 +1000
+++ valgrind-x86/coregrind/vg_main.c 2004-08-31 10:02:43.204375744 +1000
@@ -415,6 +415,10 @@
vgexecfd = auxv->u.a_val;
found |= 2;
break;
+ case AT_PHDR:
+ VG_(valgrind_base) = PGROUNDDN(auxv->u.a_val);
+ break;
+
}
if ( found != (1|2) ) {
@@ -429,6 +433,7 @@
/*====================================================================*/
/*=== Address space determination ===*/
/*====================================================================*/
+extern char _start[];
static void layout_remaining_space(Addr argc_addr, float ratio)
{
@@ -436,7 +441,10 @@
void* vres;
addr_t client_size, shadow_size;
- VG_(valgrind_base) = (addr_t)&kickstart_base;
+ // VG_(valgrind_base) should have been set by scan_auxv, but if not,
+ // this is a workable approximation
+ if (VG_(valgrind_base) == 0)
+ VG_(valgrind_base) = PGROUNDDN(&_start);
// VG_(valgrind_end) has a slightly different meaning to all the other
// VG_(*_end) vars -- ie. it names the last byte, whereas the others
diff -urN valgrind-cvs/helgrind/Makefile.am valgrind-x86/helgrind/Makefile.am
--- valgrind-cvs/helgrind/Makefile.am 2004-08-24 18:26:22.000000000 +1000
+++ valgrind-x86/helgrind/Makefile.am 2004-08-31 10:06:08.313345648 +1000
@@ -14,8 +14,8 @@
vgskin_helgrind_so_LDFLAGS = -shared
vgpreload_helgrind_so_SOURCES =
-vgpreload_helgrind_so_LDADD = $(top_builddir)/coregrind/vg_replace_malloc.o
-vgpreload_helgrind_so_DEPENDENCIES = $(top_builddir)/coregrind/vg_replace_malloc.o
+vgpreload_helgrind_so_LDADD = $(top_builddir)/coregrind/lib_replace_malloc.a
+vgpreload_helgrind_so_DEPENDENCIES = $(top_builddir)/coregrind/lib_replace_malloc.a
vgpreload_helgrind_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst
hgincludedir = $(includedir)/valgrind
diff -urN valgrind-cvs/massif/Makefile.am valgrind-x86/massif/Makefile.am
--- valgrind-cvs/massif/Makefile.am 2004-08-24 18:26:23.000000000 +1000
+++ valgrind-x86/massif/Makefile.am 2004-08-31 09:51:09.086325736 +1000
@@ -14,8 +14,8 @@
vgskin_massif_so_LDFLAGS = -shared
vgpreload_massif_so_SOURCES =
-vgpreload_massif_so_LDADD = $(top_builddir)/coregrind/vg_replace_malloc.o
-vgpreload_massif_so_DEPENDENCIES = $(top_builddir)/coregrind/vg_replace_malloc.o
+vgpreload_massif_so_LDADD = $(top_builddir)/coregrind/lib_replace_malloc.a
+vgpreload_massif_so_DEPENDENCIES = $(top_builddir)/coregrind/lib_replace_malloc.a
vgpreload_massif_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst
all-local:
diff -urN valgrind-cvs/memcheck/Makefile.am valgrind-x86/memcheck/Makefile.am
--- valgrind-cvs/memcheck/Makefile.am 2004-08-24 18:26:23.000000000 +1000
+++ valgrind-x86/memcheck/Makefile.am 2004-08-31 09:51:47.824426968 +1000
@@ -15,8 +15,8 @@
vgpreload_memcheck_so_SOURCES = \
mac_replace_strmem.c
-vgpreload_memcheck_so_LDADD = $(top_builddir)/coregrind/vg_replace_malloc.o
-vgpreload_memcheck_so_DEPENDENCIES = $(top_builddir)/coregrind/vg_replace_malloc.o
+vgpreload_memcheck_so_LDADD = $(top_builddir)/coregrind/lib_replace_malloc.a
+vgpreload_memcheck_so_DEPENDENCIES = $(top_builddir)/coregrind/lib_replace_malloc.a
vgpreload_memcheck_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst
vgskin_memcheck_so_SOURCES = \
|
|
From: Eric E. <eri...@fr...> - 2004-08-31 00:44:35
|
Julian Seward wrote: > Eric > > I think your Valgui patches have created some interesting discussions > and thinking a bit about GUIs in the future, and that's a good thing. > But at the moment there doesn't seem to be enough support to put your > patch into the tree. I suspect the GUI issue is something that will > be returned to in the future, though. You're right. I'll work on my release, keeping the patch as-is (with extra string for valgrind --version). I hope that there will be enough feedback after my first initial release. Maybe I'll not miss the next Valgrind release once more... Could we at least statuate on one thing: the name/format of the argument triggering the 'special' output ? For now I'm using --fmt=valgui, but --format=valgui may be more appropriate/explicit. Not that I really care, but I'd rather have things fixed definitely... Cheers -- Eric |
|
From: Julian S. <js...@ac...> - 2004-08-31 00:23:11
|
> That's my last change before the release; I won't touch anything else. Good. I think I too am done committing. Please, nobody commit anything for the time being. Now I wait for the nightly builds. J |
|
From: Julian S. <js...@ac...> - 2004-08-31 00:15:25
|
CVS commit by jseward: --> 2.2.0 M +1 -1 configure.in 1.122 --- valgrind/configure.in #1.121:1.122 @@ -1,4 +1,4 @@ # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 2.1.3.CVS, val...@li...) +AC_INIT(Valgrind, 2.2.0, val...@li...) AC_CONFIG_SRCDIR(coregrind/vg_main.c) AM_CONFIG_HEADER(config.h) |
|
From: Julian S. <js...@ac...> - 2004-08-31 00:15:09
|
CVS commit by jseward: version -> 2.2.0 M +2 -2 manual.html 1.50 --- valgrind/docs/manual.html #1.49:1.50 @@ -26,6 +26,6 @@ <a name="title"> </a> -<h1 align=center>Valgrind, version 2.1.2</h1> -<center>This manual was last updated on 18 July 2004</center> +<h1 align=center>Valgrind, version 2.2.0</h1> +<center>This manual was last updated on 31 August 2004</center> <p> |
|
From: Julian S. <js...@ac...> - 2004-08-31 00:14:07
|
CVS commit by jseward: Hopefully final changes for 2.2.0. M +5 -1 NEWS 1.26 --- valgrind/NEWS #1.25:1.26 @@ -38,4 +38,6 @@ * Improved SSE2/SSE3 support. +* Time-stamped output; use --time-stamp=yes + @@ -78,5 +80,5 @@ 87089 memalign( 4, xxx) makes valgrind assert -86407 Add partial support for the low-level parallel port driver ioctls. +86407 Add support for low-level parallel port driver ioctls. 70587 Add timestamps to Valgrind output? (wishlist) @@ -118,4 +120,6 @@ so that we don't generate ugly warnings by trying to compile it. +* Add support for POSIX clocks and timers. + |
|
From: Julian S. <js...@ac...> - 2004-08-31 00:13:18
|
CVS commit by jseward:
Add comments about limitations wrt self-modifying code.
M +18 -3 coregrind_core.html 1.34
--- valgrind/coregrind/docs/coregrind_core.html #1.33:1.34
@@ -1115,6 +1115,6 @@
We now use the standard Unix <code>./configure</code>,
<code>make</code>, <code>make install</code> mechanism, and I have
-attempted to ensure that it works on machines with kernel 2.2 or 2.4
-and glibc 2.1.X or 2.2.X. I don't think there is much else to say.
+attempted to ensure that it works on machines with kernel 2.4 or 2.6
+and glibc 2.2.X or 2.3.X. I don't think there is much else to say.
There are no options apart from the usual <code>--prefix</code> that
you should give to <code>./configure</code>.
@@ -1169,5 +1169,5 @@
<p>Valgrind will run x86-GNU/Linux ELF dynamically linked binaries, on
-a kernel 2.2.X or 2.4.X system, subject to the following constraints:
+a kernel 2.4.X or 2.6.X system, subject to the following constraints:
<ul>
@@ -1242,4 +1242,19 @@
translations when running (eg) a web browser.
</li>
+ <p>
+
+ <li>Valgrind can handle dynamically-generated code just fine.
+ However, if you regenerate code over the top of old code
+ (ie. at the same memory addresses) Valgrind will not realise the
+ code has changed, and will run its old translations, which will
+ be out-of-date. You need to use the VALGRIND_DISCARD_TRANSLATIONS
+ client request in that case. For the same reason gcc's
+ <a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html">
+ trampolines for nested functions</a> are currently
+ unsupported, see <a href="http://bugs.kde.org/show_bug.cgi?id=69511">
+ bug 69511</a>.
+ </li>
+ <p>
+
</ul>
|
|
From: Julian S. <js...@ac...> - 2004-08-30 23:56:21
|
On Monday 30 August 2004 20:19, Eric Estievenart wrote: > Julian Seward wrote: > > Ok, folks, this is the final call for 2.2.0. I've updated NEWS, > > Mmmmm. Still my dwarf2 updates + small updates for Valgui ? > Never mind I try. Could people who would be interested > but had no time to have a look at it send me an email ? > > Did some people have a look, I didn't get many feedback > (but didn't ask for, though....) Eric I think your Valgui patches have created some interesting discussions and thinking a bit about GUIs in the future, and that's a good thing. But at the moment there doesn't seem to be enough support to put your patch into the tree. I suspect the GUI issue is something that will be returned to in the future, though. J |
|
From: Julian S. <js...@ac...> - 2004-08-30 23:35:33
|
On Monday 30 August 2004 23:17, Tom Hughes wrote: > In message <240...@we...> > > "Jeroen N. Witmond" <jn...@xs...> wrote: > > Then I'm afraid something went wrong with that commit. I cannot find > > 'struct vki_itimerspec' in file include/vg_kerneliface.h, and > > http://webcvs.kde.org/cgi-bin/cvsweb.cgi/valgrind/include/?sortby=date > > shows the file to be 2 weeks old. > > No, you're probably just looking at a mirror rather than the master > site - changes can take a while to propagate. Yeh, it's a propagation problem. I just cvs up'd and it all works for me. J |
|
From: Paul M. <pa...@sa...> - 2004-08-30 23:02:15
|
Sebastian Biallas writes: > Slightly off-topic, but I just looked on how gcc does this on powerpc. > There gcc calls __trampoline_setup which has to manually invalidate the > instruction cache lines. I'm happy that I decided to emulate such a > clean processor design :) Yes, and Valgrind on PowerPC doesn't have any problems with self-modifying code, because when the simulated cpu encounters the icbi (instruction cache block invalidate) instruction, we invalidate any translations that overlap the specified cache line. Essentially, V's translation cache is equivalent to a real processor's instruction cache. Paul. |
|
From: Tom H. <th...@cy...> - 2004-08-30 22:17:39
|
In message <240...@we...>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> Then I'm afraid something went wrong with that commit. I cannot find
> 'struct vki_itimerspec' in file include/vg_kerneliface.h, and
> http://webcvs.kde.org/cgi-bin/cvsweb.cgi/valgrind/include/?sortby=date
> shows the file to be 2 weeks old.
No, you're probably just looking at a mirror rather than the master
site - changes can take a while to propagate.
Try cvs.kde.org if you're using another site, and see if that has
the update or not. I've just updated one of my other checkouts from
that site and it definitely got the edit.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-08-30 22:14:21
|
Then I'm afraid something went wrong with that commit. I cannot find 'struct vki_itimerspec' in file include/vg_kerneliface.h, and http://webcvs.kde.org/cgi-bin/cvsweb.cgi/valgrind/include/?sortby=date shows the file to be 2 weeks old. Jeroen. > In message <896...@we...> > "Jeroen N. Witmond" <jn...@xs...> wrote: > >> On Valgrind-CVS, updated Aug 30 (today) 23:28 CEST, I get compile >> errors: >> >> valgrind/coregrind/vg_syscalls.c: In function `before_timer_settime': >> valgrind/coregrind/vg_syscalls.c:5782: error: invalid application of >> `sizeof' to an incomplete type >> valgrind/coregrind/vg_syscalls.c:5785: error: invalid application of >> `sizeof' to an incomplete type >> valgrind/coregrind/vg_syscalls.c: In function `after_timer_settime': >> valgrind/coregrind/vg_syscalls.c:5792: error: invalid application of >> `sizeof' to an incomplete type >> valgrind/coregrind/vg_syscalls.c: In function `before_timer_gettime': >> valgrind/coregrind/vg_syscalls.c:5799: error: invalid application of >> `sizeof' to an incomplete type >> valgrind/coregrind/vg_syscalls.c: In function `after_timer_gettime': >> valgrind/coregrind/vg_syscalls.c:5805: error: invalid application of >> `sizeof' to an incomplete type >> >> The problem is in 'struct vki_itimerspec'. In what file is this struct >> defined? > > It's in include/vg_kerneliface.h and it was committed about half an > hour after the change to vg_syscalls.c because I forgot it at first. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:47:39
|
Hi! Here's an update against http://developer.kde.org/~sewardj/docs-2.1.2/coregrind_core.html#limits reflecting a) valgrind supports 2.6.X kernels (to my knownledge, runs fine here, and uses even structs from 2.6.X kernels in the include files) b) Limitation about self-modifying code. Sebastian |
|
From: Tom H. <th...@cy...> - 2004-08-30 21:42:11
|
In message <896...@we...>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> On Valgrind-CVS, updated Aug 30 (today) 23:28 CEST, I get compile errors:
>
> valgrind/coregrind/vg_syscalls.c: In function `before_timer_settime':
> valgrind/coregrind/vg_syscalls.c:5782: error: invalid application of
> `sizeof' to an incomplete type
> valgrind/coregrind/vg_syscalls.c:5785: error: invalid application of
> `sizeof' to an incomplete type
> valgrind/coregrind/vg_syscalls.c: In function `after_timer_settime':
> valgrind/coregrind/vg_syscalls.c:5792: error: invalid application of
> `sizeof' to an incomplete type
> valgrind/coregrind/vg_syscalls.c: In function `before_timer_gettime':
> valgrind/coregrind/vg_syscalls.c:5799: error: invalid application of
> `sizeof' to an incomplete type
> valgrind/coregrind/vg_syscalls.c: In function `after_timer_gettime':
> valgrind/coregrind/vg_syscalls.c:5805: error: invalid application of
> `sizeof' to an incomplete type
>
> The problem is in 'struct vki_itimerspec'. In what file is this struct
> defined?
It's in include/vg_kerneliface.h and it was committed about half an
hour after the change to vg_syscalls.c because I forgot it at first.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:33:58
|
Sebastian Biallas wrote: > Nicholas Nethercote wrote: >> On Mon, 30 Aug 2004, Sebastian Biallas wrote: >>>> That would catch some of them. But the problem, AFAICT, with all >>>> self-modifying code detection schemes is how to handle code on the >>>> stack. For example, GCC generates snippets of code on the stack when >>>> using nested functions. >>> >>> What? I thought this is highly undefined or at least deprecated, >> >> Seemingly not, see http://bugs.kde.org/show_bug.cgi?id=69511. > > > Indeed, gcc emits "call %esp". > Slightly off-topic, but I just looked on how gcc does this on powerpc. There gcc calls __trampoline_setup which has to manually invalidate the instruction cache lines. I'm happy that I decided to emulate such a clean processor design :) Sebastian |
|
From: Jeroen N. W. <jn...@xs...> - 2004-08-30 21:33:40
|
On Valgrind-CVS, updated Aug 30 (today) 23:28 CEST, I get compile errors: valgrind/coregrind/vg_syscalls.c: In function `before_timer_settime': valgrind/coregrind/vg_syscalls.c:5782: error: invalid application of `sizeof' to an incomplete type valgrind/coregrind/vg_syscalls.c:5785: error: invalid application of `sizeof' to an incomplete type valgrind/coregrind/vg_syscalls.c: In function `after_timer_settime': valgrind/coregrind/vg_syscalls.c:5792: error: invalid application of `sizeof' to an incomplete type valgrind/coregrind/vg_syscalls.c: In function `before_timer_gettime': valgrind/coregrind/vg_syscalls.c:5799: error: invalid application of `sizeof' to an incomplete type valgrind/coregrind/vg_syscalls.c: In function `after_timer_gettime': valgrind/coregrind/vg_syscalls.c:5805: error: invalid application of `sizeof' to an incomplete type The problem is in 'struct vki_itimerspec'. In what file is this struct defined? Jeroen. > > Ok, folks, this is the final call for 2.2.0. I've updated NEWS, > hopefully appropriately. Let me know if there's anything else > to go in. Nick, I'm assuming you'll commit your fix for #78765. > I'll update docs, version numbers, etc, later this evening. > > If tonight's autobuilds don't show any unusual breakage, I'll > tag the tree tomorrow morning, and run with that. > > J > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:27:30
|
Julian Seward wrote: >>>and with NX-aware processores and kernels it will no longer work. >> >>I'm no expert on that stuff, but I believe that GCC just turns off the >>no-exec functionality in such systems in these cases. Nasty, huh? > > > If the NX functionality is turnable-offable from user-space, how can it > have any value as a security enhancement mechanism? > > /me suspects /me has misunderstood something. The NX feature should harden your application against buffer-overflows[1]. But NX is a protection against remote exploits, not against locale exploits. If an attacker has sucessfully injected (and executed) code into your system, he has already won, there is no need to turn off NX :) And of course you can't switch off NX for files you don't have write access to (it's encoded in the header of the files, not in your ~/.nxconf ;) ). > > J > Sebastian [1] Note that NX without address space randomization is almost useless, but that's another story. |
|
From: Tom H. <th...@cy...> - 2004-08-30 21:18:29
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > > and with NX-aware processores and kernels it will no longer work.
> >
> > I'm no expert on that stuff, but I believe that GCC just turns off the
> > no-exec functionality in such systems in these cases. Nasty, huh?
>
> If the NX functionality is turnable-offable from user-space, how can it
> have any value as a security enhancement mechanism?
It can't be turned on and off on the fly, but gcc and the linker
can co-operate to mark an ELF file as needing (or not needing) an
executable stack and the kernel will pay attention to that when
starting the program.
So if you have a program that has an executable stack then it is
protected, but other programs are.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-08-30 21:13:49
|
> > and with NX-aware processores and kernels it will no longer work. > > I'm no expert on that stuff, but I believe that GCC just turns off the > no-exec functionality in such systems in these cases. Nasty, huh? If the NX functionality is turnable-offable from user-space, how can it have any value as a security enhancement mechanism? /me suspects /me has misunderstood something. J |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 21:04:54
|
Robert Walsh wrote: >>Indeed, gcc emits "call %esp". > > Interesting. Could be a way of spotting the problem - just Do Something > for that specific call. No, gcc also uses different registers there, depending on optimization level etc. And you have no (real) change to detect this when gcc just passes a pointer to the stack containing code (like in this example). [NB: The "call %esp" in my test was a result of inlining "static void call_func(void (*sel)(void))" from the bug report. It's quite interesting that gcc no longer understands it's own mess after inlining this function, and so is unable to optimize the trampoline code away] > > Regards, > Robert. > > Sebastian |
|
From: Robert W. <rj...@du...> - 2004-08-30 20:53:34
|
> Indeed, gcc emits "call %esp". Interesting. Could be a way of spotting the problem - just Do Something for that specific call. Regards, Robert. |
|
From: Sebastian B. <sb...@bi...> - 2004-08-30 20:46:01
|
Nicholas Nethercote wrote: > On Mon, 30 Aug 2004, Sebastian Biallas wrote: > >>> That would catch some of them. But the problem, AFAICT, with all >>> self-modifying code detection schemes is how to handle code on the >>> stack. For example, GCC generates snippets of code on the stack when >>> using nested functions. >> >> What? I thought this is highly undefined or at least deprecated, > > Seemingly not, see http://bugs.kde.org/show_bug.cgi?id=69511. Indeed, gcc emits "call %esp". > >> and with NX-aware processores and kernels it will no longer work. > > I'm no expert on that stuff, but I believe that GCC just turns off the > no-exec functionality in such systems in these cases. Nasty, huh? Very nasty: http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/1056.html Yesterdays technology tomorrow. > > N > Sebastian |
|
From: Tom H. <th...@cy...> - 2004-08-30 20:31:45
|
CVS commit by thughes:
Add vki_itimerspec definition for POSIX timer support.
M +5 -0 vg_kerneliface.h 1.23
--- valgrind/include/vg_kerneliface.h #1.22:1.23
@@ -566,4 +566,9 @@ struct vki_timespec {
};
+/* POSIX.1b structure for timer start values and intervals. */
+struct vki_itimerspec {
+ struct vki_timespec it_interval;
+ struct vki_timespec it_value;
+};
/* STAT stuff
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-30 20:13:36
|
On Mon, 30 Aug 2004, Sebastian Biallas wrote: >> That would catch some of them. But the problem, AFAICT, with all >> self-modifying code detection schemes is how to handle code on the stack. >> For example, GCC generates snippets of code on the stack when using nested >> functions. > > What? I thought this is highly undefined or at least deprecated, Seemingly not, see http://bugs.kde.org/show_bug.cgi?id=69511. > and with NX-aware processores and kernels it will no longer work. I'm no expert on that stuff, but I believe that GCC just turns off the no-exec functionality in such systems in these cases. Nasty, huh? N |