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: Julian S. <js...@ac...> - 2003-12-24 11:45:50
|
CVS commit by jseward:
Add post-FV suppressions needed to make it tolerably quiet on SuSE 9.
With these suppressions there are now 15 stderr fails and 2 stdout
fails on SuSE 9.
M +18 -0 glibc-2.3.supp 1.9
--- valgrind/glibc-2.3.supp #1.8:1.9
@@ -174,2 +174,20 @@
obj:/opt/intel/compiler70/ia32/lib/libcxa.so.3
}
+
+##----------------------------------------------------------------------##
+## SuSE 9 after FV changes (post 2.1.0)
+
+{
+ strlen/_dl_init_paths/dl_main/_dl_sysdep_start(Cond)
+ Memcheck:Cond
+ fun:strlen
+ fun:_dl_init_paths
+ fun:dl_main
+ fun:_dl_sysdep_start
+}
+
+{
+ Ugly strchr error in /lib/ld-2.3.2.so
+ Memcheck:Cond
+ obj:/lib/ld-2.3.2.so
+}
|
|
From: Jeremy F. <je...@go...> - 2003-12-24 10:11:44
|
CVS commit by fitzhardinge:
Statically allocate a page in the client address space for trampoline
code. Currently this is just for signal returns, but there's the start
of sysinfo/vsyscalls support, as used by the TLS libraries.
M +17 -10 stage2.c 1.3
M +4 -1 ume.c 1.3
M +22 -6 vg_helpers.S 1.26
M +12 -5 vg_include.h 1.164
M +4 -1 vg_main.c 1.133
M +7 -11 vg_memory.c 1.49
M +1 -23 vg_signals.c 1.54
--- valgrind/coregrind/stage2.c #1.2:1.3
@@ -132,4 +132,6 @@ static char *copy_str(char **tab, const
higher address +-----------------+
+ | Trampoline code |
+ +-----------------+
| |
: string table :
@@ -169,4 +171,5 @@ static Addr setup_client_stack(char **or
unsigned stacksize; /* total client stack size */
addr_t cl_esp; /* client stack base (initial esp) */
+ addr_t cl_stacktop; /* top of stack */
/* ==================== compute sizes ==================== */
@@ -216,5 +219,6 @@ static Addr setup_client_stack(char **or
sizeof(char **) + /* terminal NULL */
auxsize + /* auxv */
- ROUNDUP(stringsize, sizeof(int)); /* strings (aligned) */
+ ROUNDUP(stringsize, sizeof(int)) +/* strings (aligned) */
+ VKI_BYTES_PER_PAGE; /* page for trampoline code */
/* cl_esp is the client's stack pointer */
@@ -222,4 +226,9 @@ static Addr setup_client_stack(char **or
cl_esp = ROUNDDN(cl_esp, 16); /* make stack 16 byte aligned */
+ cl_stacktop = client_end;
+ cl_stacktop -= VKI_BYTES_PER_PAGE;
+
+ kp.cl_tramp_code = cl_stacktop;
+
if (0)
printf("stringsize=%d auxsize=%d stacksize=%d\n",
@@ -226,6 +235,7 @@ static Addr setup_client_stack(char **or
stringsize, auxsize, stacksize);
+
/* base of the string table (aligned) */
- stringbase = strtab = (char *)(client_end - ROUNDUP(stringsize, sizeof(int)));
+ stringbase = strtab = (char *)(cl_stacktop - ROUNDUP(stringsize, sizeof(int)));
kp.clstk_base = PGROUNDDN(cl_esp);
@@ -337,16 +347,13 @@ static Addr setup_client_stack(char **or
break;
-#if 1
case AT_SYSINFO:
- case AT_SYSINFO_EHDR:
- /* trash vsyscalls for now
+ /* Leave this unmolested for now, but we'll update it later
+ when we set up the client trapoline code page */
+ break;
- XXX should probably replace with our own sysinfo page so
- we can intercept sysenter syscalls too - or at least note
- the address so that we can catch jumps here
- */
+ case AT_SYSINFO_EHDR:
+ /* Trash this, because we don't reproduce it */
auxv->a_type = AT_IGNORE;
break;
-#endif
default:
--- valgrind/coregrind/ume.c #1.2:1.3
@@ -323,5 +323,5 @@ ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
fprintf(stderr, "sbrk failed while adjusting brk base: "
"perhaps we hit the datasize ulimit?\n");
- break;
+ return 0;
}
b += delta;
@@ -483,4 +483,7 @@ static int load_ELF(char *hdr, int len,
info->brkbase = mapelf(e, 0, info->setbrk); /* map the executable */
+ if (info->brkbase == 0)
+ return ENOMEM;
+
if (interp != NULL) {
/* reserve a chunk of address space for interpreter */
--- valgrind/coregrind/vg_helpers.S #1.25:1.26
@@ -43,7 +43,11 @@
position-independent.
*/
-.global VG_(signalreturn_bogusRA)
-.global VG_(signalreturn_bogusRA_length)
-VG_(signalreturn_bogusRA):
+.global VG_(trampoline_code_start)
+.global VG_(trampoline_code_length)
+.global VG_(tramp_sigreturn_offset)
+.global VG_(tramp_syscall_offset)
+
+VG_(trampoline_code_start):
+sigreturn_start:
subl $20, %esp # allocate arg block
movl %esp, %edx # %edx == &_zzq_args[0]
@@ -64,7 +68,19 @@
ud2
-VG_(signalreturn_bogusRA_length):
- .long . - VG_(signalreturn_bogusRA)
-
+ # We can point our sysinfo stuff here
+ .align 16
+syscall_start:
+ int $0x80
+ ret
+tramp_code_end:
+
+.data
+VG_(trampoline_code_length):
+ .long tramp_code_end - VG_(trampoline_code_start)
+VG_(tramp_sigreturn_offset):
+ .long sigreturn_start - VG_(trampoline_code_start)
+VG_(tramp_syscall_offset):
+ .long syscall_start - VG_(trampoline_code_start)
+.text
--- valgrind/coregrind/vg_include.h #1.163:1.164
@@ -1342,4 +1342,8 @@ typedef struct {
Addr client_end; /* end of client address space */
Addr client_mapbase; /* base address of !MAP_FIXED mappings */
+ Addr clstk_base; /* lowest address of client stack */
+ Addr clstk_end; /* highest address of client stack */
+ Addr cl_tramp_code; /* syscall+signal trampoline code */
+
Addr shadow_base; /* start of skin's shadow memory */
Addr shadow_end; /* end of skin's shadow memory */
@@ -1347,6 +1352,4 @@ typedef struct {
Addr vg_mmap_end; /* end of Valgrind's mmap area */
Addr vg_end; /* end of Valgrind's memory */
- Addr clstk_base; /* lowest address of client stack */
- Addr clstk_end; /* highest address of client stack */
} KickstartParams;
@@ -1377,4 +1380,6 @@ extern Addr VG_(client_mapbase); /* base
extern Addr VG_(clstk_base); /* client stack range */
extern Addr VG_(clstk_end);
+extern Addr VG_(client_trampoline_code);
+
extern Addr VG_(brk_base); /* start of brk */
extern Addr VG_(brk_limit); /* current brk */
@@ -1743,7 +1748,9 @@ extern void VG_(helper_DAA);
extern void VG_(helper_undefined_instruction);
-/* NOT A FUNCTION; this is a bogus RETURN ADDRESS. */
-extern Char VG_(signalreturn_bogusRA);
-extern Int VG_(signalreturn_bogusRA_length); /* length */
+/* Information about trampoline code (for signal return and syscalls) */
+extern const Char VG_(trampoline_code_start);
+extern const Int VG_(trampoline_code_length);
+extern const Int VG_(tramp_sigreturn_offset);
+extern const Int VG_(tramp_syscall_offset);
/* ---------------------------------------------------------------------
--- valgrind/coregrind/vg_main.c #1.132:1.133
@@ -125,4 +125,5 @@ Addr VG_(client_base); /* client address
Addr VG_(client_end);
Addr VG_(client_mapbase);
+Addr VG_(client_trampoline_code);
Addr VG_(clstk_base);
Addr VG_(clstk_end);
@@ -778,4 +779,5 @@ static void process_cmd_line_options ( c
case VKI_AT_SYSINFO:
VG_(sysinfo_page_exists) = True;
+ auxp[1] = (Int)(VG_(client_trampoline_code) + VG_(tramp_syscall_offset));
VG_(sysinfo_page_addr) = auxp[1];
break;
@@ -1393,4 +1395,5 @@ void VG_(main) ( const KickstartParams *
VG_(clstk_base) = kp->clstk_base;
VG_(clstk_end) = kp->clstk_end;
+ vg_assert(VG_(clstk_end) == VG_(client_end));
VG_(shadow_base) = kp->shadow_base;
@@ -1402,5 +1405,5 @@ void VG_(main) ( const KickstartParams *
VG_(libdir) = kp->libdir;
- vg_assert(VG_(clstk_end) == VG_(client_end));
+ VG_(client_trampoline_code) = kp->cl_tramp_code;
if (0) {
--- valgrind/coregrind/vg_memory.c #1.48:1.49
@@ -469,5 +469,5 @@ void VG_(mprotect_range)(Addr a, UInt le
/* Everything must be page-aligned */
vg_assert((a & (VKI_BYTES_PER_PAGE-1)) == 0);
- vg_assert((len & (VKI_BYTES_PER_PAGE-1)) == 0);
+ len = PGROUNDUP(len);
VG_(split_segment)(a);
@@ -662,14 +662,10 @@ void VG_(init_memory) ( void )
VG_(parse_procselfmaps) ( build_segment_map_callback ); /* everything */
- /* kludge: some newer kernels place a "sysinfo" page up high, with
- vsyscalls in it, and possibly some other stuff in the future. */
- if (VG_(sysinfo_page_exists)) {
- // 2003-Sep-25, njn: Jeremy thinks the sysinfo page probably doesn't
- // have any symbols that need to be loaded. So just treat it like
- // a non-executable page.
- //VG_(new_exeseg_mmap)( VG_(sysinfo_page_addr), 4096 );
- VG_TRACK( new_mem_startup, VG_(sysinfo_page_addr), 4096,
- True, True, True );
- }
+ /* initialize our trampoline page (which is also sysinfo stuff) */
+ VG_(memcpy)((void *)VG_(client_trampoline_code),
+ &VG_(trampoline_code_start),
+ VG_(trampoline_code_length));
+ VG_(mprotect)((void *)VG_(client_trampoline_code), VG_(trampoline_code_length),
+ VKI_PROT_READ|VKI_PROT_EXEC);
}
--- valgrind/coregrind/vg_signals.c #1.53:1.54
@@ -951,6 +951,4 @@ static void synth_ucontext(ThreadId tid,
}
-static Addr signalreturn_stub_addr = 0;
-
/* Set up a stack frame (VgSigContext) for the client's signal
handler. This includes the signal number and a bogus return
@@ -1010,28 +1008,8 @@ void vg_push_signal_frame ( ThreadId tid
== ((Char*)(esp_top_of_frame)) );
- /* if the sigreturn stub isn't in the client address space yet,
- allocate space for it and copy it into place. */
- if (signalreturn_stub_addr == 0) {
- UInt len = PGROUNDUP(VG_(signalreturn_bogusRA_length));
-
- signalreturn_stub_addr = VG_(client_alloc)(0, len,
- VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC,
- 0);
- VG_(memcpy)((void *)signalreturn_stub_addr, &VG_(signalreturn_bogusRA),
- VG_(signalreturn_bogusRA_length));
- VG_(mprotect)((void *)signalreturn_stub_addr, len, VKI_PROT_READ|VKI_PROT_EXEC);
- VG_TRACK(new_mem_mmap, signalreturn_stub_addr, VG_(signalreturn_bogusRA_length),
- True, False, True);
-
- if (VG_(clo_trace_signals))
- VG_(message)(Vg_DebugMsg, "Put sigreturn stub at %p-%p in client address space",
- signalreturn_stub_addr,
- signalreturn_stub_addr + VG_(signalreturn_bogusRA_length));
- }
-
/* retaddr, sigNo, psigInfo, puContext fields are to be written */
VG_TRACK( pre_mem_write, Vg_CoreSignal, tid, "signal handler frame",
(Addr)frame, offsetof(VgSigFrame, handlerArgs) );
- frame->retaddr = (UInt)signalreturn_stub_addr;
+ frame->retaddr = (UInt)VG_(client_trampoline_code)+VG_(tramp_sigreturn_offset);
frame->sigNo = sigNo;
frame->sigNo_private = sigNo;
|
|
From: Jeremy F. <je...@go...> - 2003-12-24 08:39:55
|
On Tue, 2003-12-23 at 18:22, John Carter wrote:
> The impossible happened. What's more it happened whether I was using
> the --tool=memcheck, lackey or none. So I assume that it is coregrind.
>
> I tried using gdb on valgrind, but it seems to go where gdb can't
> follow, (It exec's stage2, and somewhere in there Bad Things happen.
>
> How do you use gdb on stage2?
Well, looking up a source/line reference for 0xB8033A65 would be a good
start. Just from the look of the fault address (0xABFFEDFC), it seems
that the core is trying to do something with the client's stack. It
would be interesting to know what the value of ESP is, and what the code
at 0x101048E in your program is doing.
I sent the following to the list the other day about attaching gdb to
Valgrind. The only extra advice might be to set gdb to ignore SIGSEGV
and set a breakpoint around vg_signals.c:1760.
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);
J
|
|
From: Jeremy F. <je...@go...> - 2003-12-24 08:25:34
|
On Tue, 2003-12-23 at 13:07, Sefer Tov wrote: > Hi, > > I'm experiencing that problem as well when using the HEAD branch of the cvs. > > bash$ /opt/valgrind/bin/valgrind /bin/ls > Executable is mapped outside of range 0x80cf000-0xbffff000 > failed to load /opt/valgrind/lib/valgrind/stage2: Cannot allocate memory I just checked in a fix for this; could you update and try again? Otherwise, could you send me your generated stage2.lds? J |
|
From: Nicholas S. <nic...@cs...> - 2003-12-24 02:54:15
|
> Well, actually, no. As far as I know only calltree does this. For the > most part skins like memcheck just see the client program moving values > on/off the stack and jumping round the place, but have no concept of > calls/returns happening. The stack backtraces you see in error messages Actually, I still don't understand. Despite the fact that my points of instrumentation were meant to be function entries/exits, and as you say this isn't necessarily the case, the code added during instrumentation is _still_ being called multiple times despite the instrumented code only being executed once, isn't it? Nick |
|
From: Nicholas S. <nic...@cs...> - 2003-12-24 02:46:05
|
> > Josef Wiedendorfer is the real guru here as I think kcachegrind/calltree > manages to track calls/returns. I'm sure he can elaborate. > Ah. He's the one who originally suggested to me that it might be a linkage gotcha. I'd been digging through the calltree code to try and find out how it deals with this, but I've had little success groking it so far. > Having said all that ... what is it you are trying to achieve with > your skin? Our tool (www.cse.unsw.edu.au/~drt) currently uses compile-time instrumentation to gain call traces of programs, but this is a pain for us and users of the tools. Since valgrind wouldn't require compile-time hacks or a recompile, allows basic block instrumentation and seems to have been successfully used on a number of nontrivial programs, my supervisor thought that it would be a good idea to see if we could use it for our instrumentation instead. I've had a go at using dyninst for this (www.dyninst.org), but it's very experimental and we had limited success getting it to compile and run on our various systems (Various versions of Redhat and Debian). Cheers, Nick |
|
From: John C. <joh...@ta...> - 2003-12-24 02:22:08
|
The impossible happened. What's more it happened whether I was using the --tool=memcheck, lackey or none. So I assume that it is coregrind. I tried using gdb on valgrind, but it seems to go where gdb can't follow, (It exec's stage2, and somewhere in there Bad Things happen. How do you use gdb on stage2? ==6232== Nulgrind, a binary JIT-compiler for x86-linux. ==6232== Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote. ==6232== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==6232== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==6232== Valgrind library directory: /usr/local/lib/valgrind ==6232== Command line ==6232== ./test_sicctm ==6232== Startup, with flags: ==6232== -v ==6232== --tool=none ==6232== Reading syms from /lib/ld-2.3.2.so (0xB0000000) ==6232== object doesn't have a symbol table ==6232== object doesn't have any debug info ==6232== Reading syms from /usr/local/lib/valgrind/vgskin_none.so (0xB0018000) ==6232== Reading syms from /lib/tls/libdl-2.3.2.so (0xB0023000) ==6232== object doesn't have a symbol table ==6232== object doesn't have any debug info ==6232== Reading syms from /lib/tls/libc-2.3.2.so (0xB0026000) ==6232== object doesn't have a symbol table ==6232== object doesn't have any debug info ==6232== Reading syms from /usr/local/lib/valgrind/stage2 (0xB8000000) ==6232== Estimated CPU clock rate is 1607 MHz ==6232== REDIRECT soname:libc.so.6(__GI___errno_location) to soname:libpthread.so.0(__errno_location) ==6232== REDIRECT soname:libc.so.6(__errno_location) to soname:libpthread.so.0(__errno_location) ==6232== REDIRECT soname:libc.so.6(__GI___h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==6232== REDIRECT soname:libc.so.6(__h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==6232== REDIRECT soname:libc.so.6(__GI___res_state) to soname:libpthread.so.0(__res_state) ==6232== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0(__res_state) ==6232== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==6232== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen) ==6232== REDIRECT soname:ld-linux.so.2(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==6232== REDIRECT soname:ld-linux.so.2(strchr) to *vgpreload_memcheck.so*(strchr) ==6232== --6232-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --6232-- si_code=1 Fault EIP: 0xB8033A65; Faulting address: 0xABFFEDFC valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 750000 ==6232== at 0xB802E37C: vgPlain_core_panic (vg_mylibc.c:1180) ==6232== by 0xB802E37B: panic (vg_mylibc.c:1176) ==6232== by 0xB802E39C: vgPlain_core_panic (vg_mylibc.c:1181) ==6232== by 0xB8034FAB: vg_sync_signalhandler (vg_signals.c:1789) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==6232== at 0x101048E: ??? ==6232== by 0x100D879: ??? ==6232== by 0x101623E: ??? ==6232== by 0x1010267: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. 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-24 01:51:42
|
CVS commit by fitzhardinge:
It seems newer linkers have scripts which mention the base address twice
on one line.
M +1 -1 Makefile.am 1.4
--- valgrind/coregrind/x86/Makefile.am #1.3:1.4
@@ -18,3 +18,3 @@
-e '/^=====\+$$/d' \
-e 's/ENTRY(_start)/ENTRY(_ume_entry)/' \
- -e 's/0x08048000/kickstart_base/' > $@ || rm -f $@
+ -e 's/0x08048000/kickstart_base/g' > $@ || rm -f $@
|
|
From: Julian S. <js...@ac...> - 2003-12-24 01:51:18
|
> I've been trying to get a valgrind skin i'm tinkering with to get a > program to report whenever it calls or returns from a function. Simple as it sounds, this is a real swamp. For one thing, tail-calls from one function to another just look like plain Jmps, not JmpCall, and so you can't reliably use the mechanism you proposed. Similarly, there are 99 ways to return from a function (98 of them admittedly really stupid), such as popl %edx; jmp *%edx Josef Wiedendorfer is the real guru here as I think kcachegrind/calltree manages to track calls/returns. I'm sure he can elaborate. > Am I misunderstanding something about UCode or what? I'm sure this is a > solved problem, > since I imagine every single skin would depend on the behavior that I am > hoping for (one > call of the instrumentation code for every call/ret). Well, actually, no. As far as I know only calltree does this. For the most part skins like memcheck just see the client program moving values on/off the stack and jumping round the place, but have no concept of calls/returns happening. The stack backtraces you see in error messages are made by walking the stack when an error occurs, but nobody keeps track of when functions are entered/exited, basically because it's nearly impossible to do so reliably. Having said all that ... what is it you are trying to achieve with your skin? J |