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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Jeremy F. <je...@go...> - 2003-12-16 22:54:30
|
On Tue, 2003-12-16 at 11:10, Josef Weidendorfer wrote:
> No. It does the same as cachegrind, plus calls a handler at start of every
> basic block, and traps run_thread,pre/post_signal.
Hm, maybe there's something wrong with the signal track calls...
> ==11994== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==11994== at 0x81000C12: (within /lib/ld-2.3.2.so)
>
> Looking at /lib/ld-2.3.2.so (mapped at 4000000) with objdump:
>
> 41000c10 <_start>:
> 41000c10: 89 e0 mov %esp,%eax
> 41000c12: e8 f9 00 00 00 call 41000d10 <_dl_start>
You mean it's the call _dl_start? Does '--pointercheck=no' make a
difference?
This fault is a bit unusual, because it isn't printing any reason for
the SEGV - which generally means that it was a General Protection Fault,
which are generally caused by an out-of-segment pointer dereference
(which is unfortunately why it can't even print what the faulting
address was).
I can't see how that call on its own could generate any bad memory
accesses - it's even on the same page as the first instruction, which
presumably did work.
I'm guessing it's something strange about your instrumentation - can you
post the output of '--trace-codegen=10001'? It shouldn't be very
long...
> So the segfault happens at the very start...
>
> BTW, does FV enable running valgrind itself under control of a debugger?
You can use "--wait-for-gdb=yes" to get it to pause early so you can
attach to it. There's three different views of the process depending on
which set of symbol tables you tell gdb to use: the valgrind launcher
(aka, stage1), valgrind proper (aka stage2) or the client program.
To debug Valgrind itself, do something like this:
$ VALGRINDLIB=.in_place/ valgrind '--wait-for-gdb=yes' '--tool=memcheck' memcheck/tests/badrw &
6706
$ ==6706== Memcheck, a memory error detector for x86-linux.
==6706== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==6706== Using valgrind-2.1.0, a program supervision framework for x86-linux.
==6706== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
pid=6706
$ gdb .in_place/stage2 6706
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Attaching to program: /home/jeremy/cvs/kde/valgrind/.in_place/stage2, process 6706
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from .in_place//vgskin_memcheck.so...done.
Loaded symbols for .in_place//vgskin_memcheck.so
0xb803dede in vgPlain_do_syscall ()
>>> OK, at this point Valgrind is blocked in a pause() syscall, hence
the vgPlain_do_syscall. You can set breakpoints and so on:
(gdb) break vgSkin_update_extra
Breakpoint 1 at 0xb015b3f4: file mac_needs.c, line 511.
>>> use this to get to fall out of the pause() and keep going with the
startup
(gdb) jump *$eip
Continuing at 0xb803dede.
==6706== Estimated CPU clock rate is 602 MHz
==6706== For more details, rerun with: -v
==6706==
>>> SIGSEGVs are expected and normal - they're used for expanding the
client's stack and shadow memory updates (if your tool uses them) -
these should be invisible to the client (and the tool, since they're not
client events). Of course, some SIGSEGVs are outright errors in the
client or Valgrind. Valgrind will try to print messages in the bad
cases. Using --trace-signals=yes will show more details about these
SEGVs (normal or otherwise).
Program received signal SIGSEGV, Segmentation fault.
0xb8742674 in ?? ()
(gdb) c
Continuing.
Breakpoint 1, vgSkin_update_extra (err=0x0) at mac_needs.c:511
511 {
(gdb) bt
#0 vgSkin_update_extra (err=0x0) at mac_needs.c:511
#1 0xb804abc3 in vgSkinInternal_update_extra (err=0x1) at vg_toolint.c:77
#2 0xb80135a2 in vgPlain_maybe_record_error (tid=1, ekind=0, a=0, s=0x0,
extra=0xbfffe930) at vg_errcontext.c:408
(gdb) n
512 switch (VG_(get_error_kind)(err)) {
(gdb)
529 case OverlapErr: return sizeof(OverlapExtra);
> Oh, I misunderstood. I thought Valgrind and the client run somehow in
> different processes and different address spaces with FV... ?
No. I use the terms "client address space" and "Valgrind address
space", but they're both just sub-ranges within the one process address
space as far as the kernel is concerned.
J
|
|
From: Jeremy F. <je...@go...> - 2003-12-16 22:42:41
|
On Tue, 2003-12-16 at 14:26, Jeremy Fitzhardinge wrote: > CVS commit by fitzhardinge: > > Auto-generate stage2.lds so that the linker script matches the local > linker. > > > M +1 -1 Makefile.am 1.62 > M +1 -3 stage1.c 1.2 [POSSIBLY UNSAFE: printf] > M +6 -4 stage2.c 1.2 > M +5 -0 ume.c 1.2 [POSSIBLY UNSAFE: printf] > M +2 -0 vg_errcontext.c 1.47 > M +6 -2 vg_include.h 1.159 > M +1 -1 vg_intercept.c 1.27 > M +11 -6 vg_main.c 1.129 > M +1 -1 vg_syscalls.c 1.68 > M +10 -1 x86/Makefile.am 1.2 > R x86/stage2.lds 1.1 Oops. I thought editing the file list in the commit message would actually have an effect. Oh well, there's other fixes here too, which I'd intended to check in separately. |
|
From: Jeremy F. <je...@go...> - 2003-12-16 22:27:18
|
CVS commit by fitzhardinge:
Auto-generate stage2.lds so that the linker script matches the local
linker.
M +1 -1 Makefile.am 1.62
M +1 -3 stage1.c 1.2 [POSSIBLY UNSAFE: printf]
M +6 -4 stage2.c 1.2
M +5 -0 ume.c 1.2 [POSSIBLY UNSAFE: printf]
M +2 -0 vg_errcontext.c 1.47
M +6 -2 vg_include.h 1.159
M +1 -1 vg_intercept.c 1.27
M +11 -6 vg_main.c 1.129
M +1 -1 vg_syscalls.c 1.68
M +10 -1 x86/Makefile.am 1.2
R x86/stage2.lds 1.1
--- valgrind/coregrind/Makefile.am #1.61:1.62
@@ -1,4 +1,4 @@
-SUBDIRS = demangle . docs x86
+SUBDIRS = x86 demangle . docs
add_includes = -I$(srcdir)/demangle -I$(top_srcdir)/include -I$(srcdir)/x86
--- valgrind/coregrind/stage1.c #1.1:1.2
@@ -136,7 +136,5 @@ static void hoops(void)
info.argv = NULL;
- strcpy(buf, valgrind_lib);
- strcat(buf, "/");
- strcat(buf, stage2);
+ snprintf(buf, sizeof(buf), "%s/%s", valgrind_lib, stage2);
err = do_exec(buf, &info);
--- valgrind/coregrind/stage2.c #1.1:1.2
@@ -66,5 +66,5 @@ static int scan_auxv(void)
case AT_UME_EXECFD:
- kp.execfd = auxv->a_val;
+ kp.vgexecfd = auxv->a_val;
found |= 2;
break;
@@ -594,5 +594,5 @@ int main(int argc, char **argv)
if (!scan_auxv()) {
fprintf(stderr, "stage2 must be launched by stage1\n");
- exit(1);
+ exit(127);
}
@@ -868,5 +868,5 @@ int main(int argc, char **argv)
fprintf(stderr, "Aborting: couldn't initialize valgrind\n");
list_tools();
- exit(1);
+ exit(127);
}
@@ -901,9 +901,11 @@ int main(int argc, char **argv)
info.argv = cl_argv;
+ kp.clexecfd = open(exec, O_RDONLY);
+
{
int ret = do_exec(exec, &info);
if (ret != 0) {
fprintf(stderr, "do_exec(%s) failed: %s\n", exec, strerror(ret));
- exit(1);
+ exit(127);
}
}
--- valgrind/coregrind/ume.c #1.1:1.2
@@ -609,4 +609,9 @@ static int do_exec_inner(const char *exe
int ngrp = getgroups(32, groups);
+ if (st.st_mode & (S_ISUID | S_ISGID)) {
+ fprintf(stderr, "Can't execute suid/sgid executable %s\n", exe);
+ return EACCES;
+ }
+
if (uid == st.st_uid && !(st.st_mode & S_IXUSR))
return EACCES;
--- valgrind/coregrind/vg_errcontext.c #1.46:1.47
@@ -266,4 +266,6 @@ void do_actions_on_error(Error* err, Boo
m_ebp = tst->m_ebp;
}
+ VG_(printf)("starting gdb with eip=%p esp=%p ebp=%p\n",
+ m_eip, m_esp, m_ebp);
VG_(swizzle_esp_then_start_GDB)( m_eip, m_esp, m_ebp );
}
--- valgrind/coregrind/vg_include.h #1.158:1.159
@@ -1336,5 +1336,6 @@ typedef struct {
const Char *libdir; /* library directory */
- Int execfd; /* fd of our own (stage1) executable */
+ Int vgexecfd; /* fd of our own (stage1) executable */
+ Int clexecfd; /* fd of the client executable */
Addr client_base; /* start of client address space */
@@ -1385,5 +1386,8 @@ extern Addr VG_(valgrind_end);
/* stage1 executable file descriptor */
-extern Int VG_(execfd);
+extern Int VG_(vgexecfd);
+
+/* client executable file descriptor */
+extern Int VG_(clexecfd);
/* Path to all our library/aux files */
--- valgrind/coregrind/vg_intercept.c #1.26:1.27
@@ -63,5 +63,5 @@ int __GI_raise(int) __attribute__((alias
int gsignal(int sig)
{
- raise(sig);
+ return raise(sig);
}
--- valgrind/coregrind/vg_main.c #1.128:1.129
@@ -136,5 +136,8 @@ Addr VG_(valgrind_end);
/* stage1 (main) executable */
-Int VG_(execfd) = -1;
+Int VG_(vgexecfd) = -1;
+
+/* client executable */
+Int VG_(clexecfd) = -1;
/* Path to library directory */
@@ -1390,6 +1393,8 @@ void VG_(main) ( const KickstartParams *
vg_assert(VG_(clstk_end) == VG_(client_end));
- if (kp->execfd != -1)
- VG_(execfd) = VG_(safe_fd)(kp->execfd);
+ if (kp->vgexecfd != -1)
+ VG_(vgexecfd) = VG_(safe_fd)(kp->vgexecfd);
+ if (kp->clexecfd != -1)
+ VG_(clexecfd) = VG_(safe_fd)(kp->clexecfd);
if (0) {
@@ -1710,11 +1715,11 @@ void VG_(mash_colon_env)(Char *varp, con
look at parameters, memory, etc. You can't meaningfully get GDB to
continue the program, though; to continue, quit GDB. */
-extern void VG_(start_GDB_whilst_on_client_stack) ( void )
+void VG_(start_GDB_whilst_on_client_stack) ( void )
{
Int res;
UChar buf[100];
- VG_(sprintf)(buf, "%s -nw /proc/%d/exe %d",
- VG_(clo_GDB_path), VG_(getpid)(), VG_(getpid)());
+ VG_(sprintf)(buf, "%s -nw /proc/%d/fd/%d %d",
+ VG_(clo_GDB_path), VG_(getpid)(), VG_(clexecfd), VG_(getpid)());
VG_(message)(Vg_UserMsg, "starting GDB with cmd: %s", buf);
res = VG_(system)(buf);
--- valgrind/coregrind/vg_syscalls.c #1.67:1.68
@@ -1717,5 +1717,5 @@ PRE(execve)
VG_(sprintf)(exec, "--exec=%s", (Char *)arg1);
- VG_(sprintf)(exename, "/proc/self/fd/%d", VG_(execfd));
+ VG_(sprintf)(exename, "/proc/self/fd/%d", VG_(vgexecfd));
optlen += VG_(strlen)(exec)+1;
--- valgrind/coregrind/x86/Makefile.am #1.1:1.2
@@ -4,5 +4,4 @@
EXTRA_DIST = \
Make.inc \
- stage2.lds \
ume_archdefs.c \
ume_archdefs.h \
@@ -10,2 +9,12 @@
ume_go.c
+BUILT_SOURCES = stage2.lds
+CLEANFILES = stage2.lds
+
+# Extract ld's default linker script and hack it to our needs
+stage2.lds: Makefile
+ ld --verbose | sed \
+ -e '1,/^=====\+$$/d' \
+ -e '/^=====\+$$/d' \
+ -e 's/ENTRY(_start)/ENTRY(_ume_entry)/' \
+ -e 's/0x08048000/kickstart_base/' > $@ || rm -f $@
|
|
From: Josef W. <Jos...@gm...> - 2003-12-16 19:10:31
|
On Tuesday 16 December 2003 18:59, Jeremy Fitzhardinge wrote: > > I managed my "calltree" to compile with the FV changes, but I get a > > segfault on running: > > ... > That looks like something is trying to escape the client address space. > Try with --pointercheck=no to see if that works. Does your tool > generate LOADs or STOREs as part of it's instrumentation? At the No. It does the same as cachegrind, plus calls a handler at start of every basic block, and traps run_thread,pre/post_signal. ==11994== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==11994== at 0x81000C12: (within /lib/ld-2.3.2.so) Looking at /lib/ld-2.3.2.so (mapped at 4000000) with objdump: 41000c10 <_start>: 41000c10: 89 e0 mov %esp,%eax 41000c12: e8 f9 00 00 00 call 41000d10 <_dl_start> So the segfault happens at the very start... BTW, does FV enable running valgrind itself under control of a debugger? > > idea? I have to look at the changes. One question: Where is code for > > helpers supposed to be located? Does a helper call now involve a context > > switch?! > > No, calling a helper from generated code runs on the real CPU, and so > has no restrictions. If you want to call out from code running on the > VCPU back into Valgrind, you need to use a client request. Oh, I misunderstood. I thought Valgrind and the client run somehow in different processes and different address spaces with FV... ? Josef |
|
From: Jeremy F. <je...@go...> - 2003-12-16 17:59:38
|
On Tue, 2003-12-16 at 07:39, Josef Weidendorfer wrote: > No idea, seems to be Redhat specific. I had the same problem trying to compile > this with Suse 9.0. But it works when using the output of "ld --verbose", and > changing the lines with ENTRY(...) and first line of SECTIONS with > "kickstart_base" instead. I suppose these are the "slight > modifications" (Jeremy?). Yep, pretty much. I hadn't realized that the ONLY_IF_* stuff was a RedHatism. > Perhaps it's the best to make some "ld --verbose | sed ... " from the > Makefile, doing the needed modifications instead of supplying a full ld > script. Yes, that's probably a good idea. I'll fix it up today. > I managed my "calltree" to compile with the FV changes, but I get a segfault > on running: > =============================================== > > valgrind --tool=calltree ls > ... > ==2826== Estimated CPU clock rate is 600 MHz > ==2826== For more details, rerun with: -v > ==2826== > ==2826== Process terminating with default action of signal 11 (SIGSEGV): > dumping core > ==2826== at 0x81000C12: (within /lib/ld-2.3.2.so) > ==2826== > ... > ================================================== That looks like something is trying to escape the client address space. Try with --pointercheck=no to see if that works. Does your tool generate LOADs or STOREs as part of it's instrumentation? At the moment, the codegen assumes all LOADs and STOREs are from the client code, not the instrumentation. > As there are only minor changes in Cachegrind (which is working quite fine), I > thought the same kind of modifications should be enough. Any idea? > I have to look at the changes. One question: Where is code for helpers > supposed to be located? Does a helper call now involve a context switch?! No, calling a helper from generated code runs on the real CPU, and so has no restrictions. If you want to call out from code running on the VCPU back into Valgrind, you need to use a client request. J |
|
From: Josef W. <Jos...@gm...> - 2003-12-16 15:39:24
|
On Tuesday 16 December 2003 14:44, Dirk Mueller wrote: > On Tuesday 16 December 2003 03:14, Jeremy Fitzhardinge wrote: > > A coregrind/x86/stage2.lds 1.1 > > does anyone know what these "ONLY_IF_RO" and "ONLY_IF_RW" literals in this > file are supposed to do? No idea, seems to be Redhat specific. I had the same problem trying to compile this with Suse 9.0. But it works when using the output of "ld --verbose", and changing the lines with ENTRY(...) and first line of SECTIONS with "kickstart_base" instead. I suppose these are the "slight modifications" (Jeremy?). Perhaps it's the best to make some "ld --verbose | sed ... " from the Makefile, doing the needed modifications instead of supplying a full ld script. I managed my "calltree" to compile with the FV changes, but I get a segfault on running: =============================================== > valgrind --tool=calltree ls ... ==2826== Estimated CPU clock rate is 600 MHz ==2826== For more details, rerun with: -v ==2826== ==2826== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==2826== at 0x81000C12: (within /lib/ld-2.3.2.so) ==2826== ... ================================================== As there are only minor changes in Cachegrind (which is working quite fine), I thought the same kind of modifications should be enough. Any idea? I have to look at the changes. One question: Where is code for helpers supposed to be located? Does a helper call now involve a context switch?! Cheers, Josef |
|
From: Dirk M. <dm...@gm...> - 2003-12-16 13:44:20
|
On Tuesday 16 December 2003 03:14, Jeremy Fitzhardinge wrote: > A coregrind/x86/stage2.lds 1.1 does anyone know what these "ONLY_IF_RO" and "ONLY_IF_RW" literals in this file are supposed to do? I can't find them defined or replaced anywhere else, and it doesn't look like any binutils version available from ftp.gnu.org supports them. removing them works fine for me btw. |
|
From: Dirk M. <mu...@kd...> - 2003-12-16 13:11:18
|
On Tuesday 16 December 2003 03:14, Jeremy Fitzhardinge wrote: > A corecheck/tests/as_mmap.c 1.1 [no copyright] > A corecheck/tests/as_mmap.stderr.exp 1.1 > A corecheck/tests/as_mmap.vgtest 1.1 > A corecheck/tests/as_shm.c 1.1 [POSSIBLY UNSAFE: printf] [no > copyright] A corecheck/tests/as_shm.stderr.exp 1.1 > A corecheck/tests/as_shm.stdout.exp 1.1 > A corecheck/tests/as_shm.vgtest 1.1 > A coregrind/gen_toolint.pl 1.1 > A coregrind/stage1.c 1.1 [POSSIBLY UNSAFE: printf] [no > copyright] A coregrind/stage2.c 1.1 [POSSIBLY UNSAFE: printf] > [no copyright] A coregrind/toolfuncs.def 1.1 > A coregrind/ume.c 1.1 [POSSIBLY UNSAFE: printf,scanf] [no > copyright] A coregrind/ume.h 1.1 [no copyright] > A coregrind/ume_arch.h 1.1 [no copyright] > A coregrind/vg_skiplist.c 1.1 [no copyright] > A coregrind/x86/Makefile.am 1.1 > A coregrind/x86/stage2.lds 1.1 > A coregrind/x86/ume_archdefs.c 1.1 [no copyright] > A coregrind/x86/ume_archdefs.h 1.1 [no copyright] > A coregrind/x86/ume_entry.S 1.1 > A coregrind/x86/ume_go.c 1.1 [no copyright] > A include/vg_skin.h.base 1.1 > R coregrind/valgrind.in 1.41 > R include/vg_skin.h 1.102 can you please add copyright and license statements to the files which are listed as "no copyright" ? Thanks. |
|
From: Jeremy F. <je...@go...> - 2003-12-16 08:16:47
|
On Mon, 2003-12-15 at 22:02, Robert Walsh wrote: > > I've updated all the standard tools, and they all seem to mostly work. > > Cachegrind is having trouble with dlclose(), which I haven't > > investigated yet. > > I'm seeing corecheck/tests/as_shm failing, too: > > *** as_shm.stdout.exp 2003-12-15 21:35:38.000000000 -0800 > --- as_shm.stdout.out 2003-12-15 21:49:44.000000000 -0800 > *************** > *** 1 **** > ! shmat 0: addr=0x81156000 > --- 1 ---- > ! shmat 0: addr=0x8101c000 Yeah, that address depends on how big your libc and other libraries are, so it isn't the greatest test. J |
|
From: Robert W. <rj...@du...> - 2003-12-16 06:02:25
|
> I've updated all the standard tools, and they all seem to mostly work.=20 > Cachegrind is having trouble with dlclose(), which I haven't > investigated yet. I'm seeing corecheck/tests/as_shm failing, too: *** as_shm.stdout.exp 2003-12-15 21:35:38.000000000 -0800 --- as_shm.stdout.out 2003-12-15 21:49:44.000000000 -0800 *************** *** 1 **** ! shmat 0: addr=3D0x81156000 --- 1 ---- ! shmat 0: addr=3D0x8101c000 Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Jeremy F. <je...@go...> - 2003-12-16 02:24:01
|
CVS commit by fitzhardinge: Remove coregrind/vg_valgrinq_dummy.c R vg_valgrinq_dummy.c 1.5 |
|
From: John C. <joh...@ta...> - 2003-12-16 02:22:03
|
On Mon, 15 Dec 2003, Jeremy Fitzhardinge wrote: > * It relies on the dynamic linker, so it doesn't work for static > binaries Ooh! I love you! This means we will be able to use it on eCos synth target. (If you don't know eCos is an RTOS for embedded computers, it also has a version "synthetic" that allows you to develop, test and debug your embedded Application on your linux desktop.) Thus, by proxy, you have given the power of Valgrind to the many developers for many kinds of Arcane CPU's. Yahoooooooooooooooooooooo! John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand A Million Monkeys can inflict worse things than just Shakespeare on your system. |
|
From: Jeremy F. <je...@go...> - 2003-12-16 02:16:37
|
CVS commit by fitzhardinge: Back out unintended change M +2 -2 autogen.sh 1.3 --- valgrind/autogen.sh #1.2:1.3 @@ -12,6 +12,6 @@ } -run aclocal-1.6 +run aclocal run autoheader -run automake-1.6 -a +run automake -a run autoconf |
|
From: Jeremy F. <je...@go...> - 2003-12-16 02:15:11
|
CVS commit by fitzhardinge: Add and delete all the files which need adding and deleting. A corecheck/tests/as_mmap.c 1.1 [no copyright] A corecheck/tests/as_mmap.stderr.exp 1.1 A corecheck/tests/as_mmap.vgtest 1.1 A corecheck/tests/as_shm.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/as_shm.stderr.exp 1.1 A corecheck/tests/as_shm.stdout.exp 1.1 A corecheck/tests/as_shm.vgtest 1.1 A coregrind/gen_toolint.pl 1.1 A coregrind/stage1.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A coregrind/stage2.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A coregrind/toolfuncs.def 1.1 A coregrind/ume.c 1.1 [POSSIBLY UNSAFE: printf,scanf] [no copyright] A coregrind/ume.h 1.1 [no copyright] A coregrind/ume_arch.h 1.1 [no copyright] A coregrind/vg_skiplist.c 1.1 [no copyright] A coregrind/x86/Makefile.am 1.1 A coregrind/x86/stage2.lds 1.1 A coregrind/x86/ume_archdefs.c 1.1 [no copyright] A coregrind/x86/ume_archdefs.h 1.1 [no copyright] A coregrind/x86/ume_entry.S 1.1 A coregrind/x86/ume_go.c 1.1 [no copyright] A include/vg_skin.h.base 1.1 R coregrind/valgrind.in 1.41 R include/vg_skin.h 1.102 |
|
From: Jeremy F. <je...@go...> - 2003-12-16 02:05:54
|
CVS commit by fitzhardinge: This jumbo-checkin is the Full Virtualization checkin. This eliminates Valgrind's dependency on the dynamic linker for getting started, and instead takes things into its own hands. This checkin doesn't add much in the way of new functionality, but it is the basis for all future work on Valgrind. It allows us much more flexibility in implementation, and well as increasing the reliability of Valgrind by protecting it more from its clients. This patch requires some changes to tools to update them to the changes in the tool API, but they are straightforward. See the posting "Heads up: Full Virtualization" on valgrind-developers for a more complete description of this change and its effects on you. M +7 -3 Makefile.am 1.60 M +2 -2 autogen.sh 1.2 M +1 -1 configure.in 1.102 M +2 -0 valgrind.spec.in 1.11 M +12 -3 addrcheck/Makefile.am 1.47 M +33 -31 addrcheck/ac_main.c 1.56 M +6 -0 cachegrind/Makefile.am 1.41 M +2 -2 cachegrind/cg_main.c 1.58 M +6 -0 corecheck/Makefile.am 1.41 M +2 -2 corecheck/cc_main.c 1.18 M +8 -3 corecheck/tests/Makefile.am 1.18 M +92 -48 coregrind/Makefile.am 1.61 M +2 -1 coregrind/valgrind.vs 1.3 M +26 -0 coregrind/vg_constants.h 1.13 M +2 -87 coregrind/vg_default.c 1.19 M +18 -1 coregrind/vg_dispatch.S 1.12 M +92 -25 coregrind/vg_from_ucode.c 1.67 M +9 -10 coregrind/vg_helpers.S 1.25 M +203 -135 coregrind/vg_include.h 1.158 M +54 -122 coregrind/vg_intercept.c 1.26 M +53 -43 coregrind/vg_libpthread.c 1.141 M +194 -18 coregrind/vg_libpthread.vs 1.7 M +235 -479 coregrind/vg_main.c 1.128 M +84 -15 coregrind/vg_malloc2.c 1.16 M +685 -146 coregrind/vg_memory.c 1.45 M +143 -13 coregrind/vg_mylibc.c 1.60 M +29 -134 coregrind/vg_needs.c 1.13 M +41 -5 coregrind/vg_procselfmaps.c 1.10 M +3 -4 coregrind/vg_proxylwp.c 1.9 M +176 -170 coregrind/vg_replace_malloc.c 1.16 M +88 -15 coregrind/vg_scheduler.c 1.133 M +124 -9 coregrind/vg_signals.c 1.53 M +1 -1 coregrind/vg_stabs.c 1.2 M +0 -130 coregrind/vg_startup.S 1.20 M +369 -150 coregrind/vg_symtab2.c 1.65 M +7 -1 coregrind/vg_symtab2.h 1.4 M +326 -87 coregrind/vg_syscalls.c 1.67 M +2 -1 coregrind/vg_to_ucode.c 1.115 M +41 -30 coregrind/vg_translate.c 1.63 M +14 -0 coregrind/vg_transtab.c 1.26 M +4 -3 example/ex_main.c 1.14 M +12 -1 helgrind/Makefile.am 1.44 M +25 -23 helgrind/hg_main.c 1.69 M +12 -1 include/Makefile.am 1.5 M +7 -0 include/vg_constants_skin.h 1.6 M +5 -0 include/vg_kerneliface.h 1.9 M +667 -243 include/vg_skin.h 1.102 M +6 -0 lackey/Makefile.am 1.42 M +3 -2 lackey/lk_main.c 1.22 M +13 -4 memcheck/Makefile.am 1.47 M +1 -4 memcheck/mac_leakcheck.c 1.12 M +22 -2 memcheck/mac_replace_strmem.c 1.8 M +4 -0 memcheck/mc_clientreqs.c 1.17 M +3 -3 memcheck/mc_from_ucode.c 1.13 M +39 -39 memcheck/mc_main.c 1.43 M +4 -1 memcheck/memcheck.h 1.16 M +1 -1 memcheck/tests/badjump.stderr.exp 1.7 M +1 -1 memcheck/tests/fprw.vgtest 1.4 M +0 -1 memcheck/tests/nanoleak.supp 1.2 M +1 -0 memcheck/tests/sigaltstack.c 1.6 M +0 -3 memcheck/tests/sigaltstack.stderr.exp 1.8 M +4 -7 memcheck/tests/threadederrno.c 1.2 [POSSIBLY UNSAFE: printf] M +0 -3 memcheck/tests/threadederrno.stderr.exp 1.2 M +3 -3 memcheck/tests/threadederrno.stdout.exp 1.2 M +3 -0 memcheck/tests/zeropage.stderr.exp 1.2 M +6 -1 none/Makefile.am 1.42 M +20 -13 none/nl_main.c 1.17 M +1 -1 none/tests/Makefile.am 1.16 M +5 -1 none/tests/smc1.c 1.3 M +5 -5 none/tests/smc1.stdout.exp 1.3 M +4 -0 tests/filter_stderr_basic 1.12 M +1 -3 tests/vg_regtest.in 1.17 |
|
From: Jeremy F. <je...@go...> - 2003-12-16 02:04:13
|
Hi all,
You may have seen some references to "full virtualization" (or FV). This
is the work I've been doing to restructure the way that Valgrind relates
to its client.
Currently, Valgrind relies on using LD_PRELOAD to hook itself into the
client early in its execution. This has several problems:
* It doesn't get in early enough, so some unknown amount of code
has run before Valgrind starts
* It relies on the dynamic linker, so it doesn't work for static
binaries
* Valgrind and the client share a dynamic linker, which means that
Valgrind can't use any standard libraries
* Client state and Valgrind state are intermingled in memory, so a
stray client memory write can cause Valgrind to crash or
misbehave
The FV changes remove all these limitations. Valgrind no longer relies
on the dynamic linker - it actually loads the client's ELF executable
itself, and starts it from the very first instruction under Valgrind
control.
It also means that there's a much stricter barrier between Valgrind and
the client, akin to the barrier between the kernel and user-space.
Valgrind's use of the dynamic linker, libraries, etc is completely
independent of the client's. In addition, the client address space is
self-contained, with Valgrind's memory near the top of the address
space. Valgrind takes advantage of that by generating bounds checks on
client memory accesses, so they are prohibited from going outside the
client address space (this is done with x86 segmentation, and so adds
little or no extra overhead).
All the client's address-space manipulation syscalls (mmap, shmat, brk,
etc) are vetted to make sure that they are constrained within the client
address space. Some special ioctls which can create mappings (like the
DRI ioctls) can create mappings outside the client address space, which
can cause problems (at the very least it will cause the client to take
an exception with --pointercheck=yes).
For users, there shouldn't be much in the way visible changes. Apart
from static executables working, the main visible difference is in the
valgrind command, which is now an executable rather than a script. It
supports all the same options, as well as the VALGRIND_OPTS environment
variable.
The changes are bigger for Valgrind developers. Over time, we can start
dissolving vg_mylibc.c, and use standard library functions instead. We
can also consider using new libraries and languages. There are now
fewer restrictions on programming within Valgrind; the main one is that
direct use of mmap/munmap/mprotect() is discouraged, because we need
still need to be careful about where things are placed in the address
space, and track where things are. VG_(mmap) does its own memory
placement algorithm so that Valgrind's mmaps don't accidentally appear
in the client address space. There are also a few extra VKI_MAP_* flags
to control various Valgrind-specific mmap behaviours.
For tool (aka skin) authors, there have been a few changes in the tool
interface. Within the core, the tool interface functions are all
defined in coregrind/toolfuncs.def, which is used to generate vg_skin.h
and other files. This cuts down on a lot of tedious typing whenever a
new tool interface is added or changed; the cost is that perl is now
required for building (as opposed to just running the regression tests).
The tool interface itself has been changed a bit:
The VG_DETERMINE_INTERFACE_VERSION macro now takes two
arguments: a pointer to the tools pre_clo_init function (which
need not have any particular name, and may be static; and the
tools requirements for shadow memory, expressed as a floating
point number which is the shadow:client memory ratio (so
addrcheck uses 1/8th the client memory in shadow memory, since
it uses one bit per byte; memcheck uses 9/8ths the client
memory, because it has 8 V bits and 1 A bit per byte).
All the SK_(track_*) functions have been renamed to
SK_(init_*). This is because all tool entrypoints can be
explicitly set with a corresponding SK_(init_*) function, rather
than relying on functions with special names (though the special
names still work). The intention of this is to move away from
special filenames, since it can be a bit fragile if the names
change (if you rename the function in the core without updating
the tool, then the tool may silently fail to work, rather than
alerting you to the rename at compile time).
There's a special area of memory for shadow data. As I
mentioned above, the tool's init now has to tell the core how
much shadow memory it wants to use. There are now two ways of
using shadow memory:
1. You can allocate page-sized chunks of the shadow memory
with VG_(shadow_alloc)(size). This just returns a
pointer to the next piece of free shadow memory. If it
runs out (ie, you ask for more shadow memory than you
said you would), it panics.
2. You can also treat all shadow memory as a big array.
This array is incrementally initialized as you touch
it. The first time you touch a particular shadow page,
it calls your SK_(init_shadow_page) function to
initialize that page. This is basically called from a
signal handler, so you have to be careful to keep this
function as simple as possible.
Shadow memory is from VG_(shadow_base)() to VG_(shadow_end)().
The tools are running in a very different context from the
client code. This means that if you want to override some
client functions, you can't just declare them and expect your
code to be run by the client. You need to create a separate .so
file for your tool, called vgpreload_TOOLNAME.so. If the core
sees this when it loads your tool, it also sets the client
environment up to LD_PRELOAD this into the client address
space. If you want to replace the malloc calls, you can also
link coregrind/vg_replace_malloc.o into your vgpreload_*.so
file.
Similarly, if you want to allocate something in the client
address space, you need to use VG_(cli_malloc/free). If you
pass a pointer to the client which is in the Valgrind address
space, it won't be able to dereference it. Similarly, you
cannot call code which is in the Valgrind core or tool from the
client - you must arrange for the code to be in the client
address space.
You can look at the changes to memcheck and addrcheck to see all of
these being put to use (well, not shadow memory as a virtual array). In
general it only takes a few minutes to update a tool to the new
interface.
I've updated all the standard tools, and they all seem to mostly work.
Cachegrind is having trouble with dlclose(), which I haven't
investigated yet.
Oh, and the --in-place=<path> command-line option has gone. Its
replacement is the VALGRINDLIB environment variable. The build process
creates a $topdir/.in_place directory which is populated with symlinks
to the newly built core and tools, so you can use 'VALGRINDLIB=.in_place
coregrind/valgrind ...' to run it in place.
I've been testing this pretty solidly for a while, so I think it should
work OK. No doubt you'll find some problems, but that's why I'm
checking it in (and why we did the 2.1.0 release *before* checking it in
- so that there's something semi-stable for people to play with).
J
|
|
From: Jeremy F. <je...@go...> - 2003-12-16 01:49:27
|
CVS commit by fitzhardinge:
Change the --track-fds code to use VG_AR_CORE rather than
VG_(malloc)/(strdup), which puts things into VG_AR_SKIN.
M +9 -2 vg_mylibc.c 1.59
M +7 -7 vg_syscalls.c 1.66
--- valgrind/coregrind/vg_mylibc.c #1.58:1.59
@@ -969,6 +969,13 @@ __inline__ Char* VG_(arena_strdup) ( Are
{
Int i;
- Int len = VG_(strlen)(s) + 1;
- Char* res = VG_(arena_malloc) (aid, len);
+ Int len;
+ Char* res;
+
+ if (s == NULL)
+ return NULL;
+
+ len = VG_(strlen)(s) + 1;
+ res = VG_(arena_malloc) (aid, len);
+
for (i = 0; i < len; i++)
res[i] = s[i];
--- valgrind/coregrind/vg_syscalls.c #1.65:1.66
@@ -292,5 +292,5 @@ Char *resolve_fname(Int fd)
return NULL;
- return ((buf[0] == '/') ? VG_(strdup)(buf) : NULL);
+ return ((buf[0] == '/') ? VG_(arena_strdup)(VG_AR_CORE, buf) : NULL);
}
@@ -312,6 +312,6 @@ void record_fd_close(Int tid, Int fd)
i->next->prev = i->prev;
if(i->pathname)
- VG_(free) (i->pathname);
- VG_(free) (i);
+ VG_(arena_free) (VG_AR_CORE, i->pathname);
+ VG_(arena_free) (VG_AR_CORE, i);
fd_count--;
break;
@@ -340,5 +340,5 @@ void record_fd_open(Int tid, Int fd, cha
while (i) {
if (i->fd == fd) {
- if (i->pathname) VG_(free)(i->pathname);
+ if (i->pathname) VG_(arena_free)(VG_AR_CORE, i->pathname);
break;
}
@@ -348,5 +348,5 @@ void record_fd_open(Int tid, Int fd, cha
/* Not already one: allocate an OpenFd */
if (i == NULL) {
- i = VG_(malloc)(sizeof(OpenFd));
+ i = VG_(arena_malloc)(VG_AR_CORE, sizeof(OpenFd));
i->prev = NULL;
@@ -3351,5 +3351,5 @@ POST(open)
} else {
if(VG_(clo_track_fds))
- record_fd_open(tid, res, VG_(strdup)((Char*)arg1));
+ record_fd_open(tid, res, VG_(arena_strdup)(VG_AR_CORE, (Char*)arg1));
}
MAYBE_PRINTF("%d\n",res);
@@ -3395,5 +3395,5 @@ POST(creat)
} else {
if(VG_(clo_track_fds))
- record_fd_open(tid, res, VG_(strdup)((Char*)arg1));
+ record_fd_open(tid, res, VG_(arena_strdup)(VG_AR_CORE, (Char*)arg1));
}
MAYBE_PRINTF("%d\n",res);
|