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-22 00:15:21
|
CVS commit by jseward:
For whatever reason, ld-2.3.2.so (ld-linux.so.2) seems to have its own
PLT-bypassed versions of stpcpy and strchr. Subvert them.
M +5 -0 vg_symtab2.c 1.68
--- valgrind/coregrind/vg_symtab2.c #1.67:1.68
@@ -2177,4 +2177,9 @@ void VG_(setup_code_redirect_table) ( vo
VG_(add_redirect_sym)("soname:libc.so.6", "stpcpy",
"*vgpreload_memcheck.so*", "stpcpy");
+
+ VG_(add_redirect_sym)("soname:ld-linux.so.2", "stpcpy",
+ "*vgpreload_memcheck.so*", "stpcpy");
+ VG_(add_redirect_sym)("soname:ld-linux.so.2", "strchr",
+ "*vgpreload_memcheck.so*", "strchr");
}
|
|
From: Julian S. <js...@ac...> - 2003-12-21 23:55:29
|
CVS commit by jseward:
Use the redir machinery to forcibly remap stpcpy in libc.so.6 to our
own version in mac_replace_strmem.c. We have to do this the hard way
because overenthusiastic PLT bypassing in glibc means the usual
symbol-override stuff doesn't work. IOW, for the usual reason that we
have to use the redir machinery at all.
This makes many programs run much more quietly on SuSE 9.
M +11 -5 vg_symtab2.c 1.67
--- valgrind/coregrind/vg_symtab2.c #1.66:1.67
@@ -2107,4 +2107,9 @@ void VG_(add_redirect_sym)(const Char *f
redir->to_addr = 0;
+ if (VG_(clo_verbosity) >= 2)
+ VG_(message)(Vg_UserMsg,
+ "REDIRECT %s(%s) to %s(%s)",
+ from_lib, from_sym, to_lib, to_sym);
+
if (!resolve_redir_allsegs(redir)) {
/* can't resolve immediately; add to list */
@@ -2164,11 +2169,12 @@ void VG_(setup_code_redirect_table) ( vo
VG_(add_redirect_sym)("soname:libc.so.6", redirects[i].from,
"soname:libpthread.so.0", redirects[i].to);
-
- if (VG_(clo_verbosity) >= 2)
- VG_(message)(Vg_UserMsg,
- "REPLACING libc(%s) with libpthread(%s)",
- redirects[i].from, redirects[i].to);
}
+ /* Overenthusiastic use of PLT bypassing by the glibc people also
+ means we need to patch the following functions to our own
+ implementations of said, in mac_replace_strmem.c.
+ */
+ VG_(add_redirect_sym)("soname:libc.so.6", "stpcpy",
+ "*vgpreload_memcheck.so*", "stpcpy");
}
|
|
From: Julian S. <js...@ac...> - 2003-12-21 23:33:13
|
CVS commit by jseward:
Make the debug printing in the symbol redirect machinery, easier to
understand.
M +22 -13 vg_symtab2.c 1.66
--- valgrind/coregrind/vg_symtab2.c #1.65:1.66
@@ -1912,4 +1912,8 @@ void VG_(mini_stack_dump) ( Addr eips[],
/*------------------------------------------------------------*/
+/* Set to True for debug printing. */
+static const Bool verbose_redir = False;
+
+
/* resolved redirections, indexed by from_addr */
typedef struct _CodeRedirect {
@@ -1986,5 +1990,4 @@ static Bool resolve_redir(CodeRedirect *
{
Bool resolved;
- static const Bool verbose = False;
vg_assert(si != NULL);
@@ -1997,6 +2000,6 @@ static Bool resolve_redir(CodeRedirect *
resolved = (redir->from_addr != 0) && (redir->to_addr != 0);
- if (verbose)
- VG_(printf)("trying to resolve %s:%s / %s:%s against %s:%s\n",
+ if (0 && verbose_redir)
+ VG_(printf)(" consider FROM binding %s:%s -> %s:%s in %s(%s)\n",
redir->from_lib, redir->from_sym,
redir->to_lib, redir->to_sym,
@@ -2010,7 +2013,7 @@ static Bool resolve_redir(CodeRedirect *
if (match_lib(redir->from_lib, si)) {
redir->from_addr = reverse_search_one_symtab(si, redir->from_sym);
- if (verbose)
- VG_(printf)("match lib %s passed; from_addr=%p\n",
- redir->from_lib, redir->from_addr);
+ if (verbose_redir && redir->from_addr != 0)
+ VG_(printf)(" bind FROM: %p = %s:%s\n",
+ redir->from_addr,redir->from_lib, redir->from_sym );
}
}
@@ -2021,7 +2024,8 @@ static Bool resolve_redir(CodeRedirect *
if (match_lib(redir->to_lib, si)) {
redir->to_addr = reverse_search_one_symtab(si, redir->to_sym);
- if (verbose)
- VG_(printf)("match lib %s passed; to_addr=%p\n",
- redir->to_lib, redir->to_addr);
+ if (verbose_redir && redir->to_addr != 0)
+ VG_(printf)(" bind TO: %p = %s:%s\n",
+ redir->to_addr,redir->to_lib, redir->to_sym );
+
}
}
@@ -2029,5 +2033,5 @@ static Bool resolve_redir(CodeRedirect *
resolved = (redir->from_addr != 0) && (redir->to_addr != 0);
- if (verbose)
+ if (0 && verbose_redir)
VG_(printf)("resolve_redir: %s:%s from=%p %s:%s to=%p\n",
redir->from_lib, redir->from_sym, redir->from_addr,
@@ -2035,6 +2039,6 @@ static Bool resolve_redir(CodeRedirect *
if (resolved) {
- if (VG_(clo_verbosity) > 2 || verbose) {
- VG_(message)(Vg_DebugMsg, "redir resolved (%s:%s=%p -> ",
+ if (VG_(clo_verbosity) > 2 || verbose_redir) {
+ VG_(message)(Vg_DebugMsg, " redir resolved (%s:%s=%p -> ",
redir->from_lib, redir->from_sym, redir->from_addr);
VG_(message)(Vg_DebugMsg, " %s:%s=%p)",
@@ -2061,4 +2065,8 @@ static void resolve_seg_redirs(SegInfo *
CodeRedirect *redir, *next;
+ if (verbose_redir)
+ VG_(printf)("Considering redirs to/from %s(soname=%s)\n",
+ si->filename, si->soname);
+
/* visit each unresolved redir - if it becomes resolved, then
remove it from the unresolved list */
|
|
From: Julian S. <js...@ac...> - 2003-12-21 23:29:47
|
CVS commit by jseward:
Add a vanilla implementation of stpcpy(). Does not do overlap checking
(it should).
M +17 -0 mac_replace_strmem.c 1.9
--- valgrind/memcheck/mac_replace_strmem.c #1.8:1.9
@@ -321,4 +321,21 @@ int memcmp ( const void *s1V, const void
}
+/* glibc-2.3.2/sysdeps/generic/stpcpy.c */
+/* Copy SRC to DEST, returning the address of the terminating '\0' in DEST. */
+char *
+stpcpy (dest, src)
+ char *dest;
+ const char *src;
+{
+ register char *d = dest;
+ register const char *s = src;
+
+ do
+ *d++ = *s;
+ while (*s++ != '\0');
+
+ return d - 1;
+}
+
/*--------------------------------------------------------------------*/
/*--- end mac_replace_strmem.c ---*/
|
|
From: Jeremy F. <je...@go...> - 2003-12-20 18:20:23
|
CVS commit by fitzhardinge:
Fix typo in VG_(munmap)() error checking, which made it never remove
any Segment mappings.
M +1 -1 vg_mylibc.c 1.63
--- valgrind/coregrind/vg_mylibc.c #1.62:1.63
@@ -307,5 +307,5 @@ Int VG_(munmap)( void* start, Int length
{
Int res = VG_(do_syscall)(__NR_munmap, (UInt)start, (UInt)length );
- if (!VG_(is_kerror))
+ if (!VG_(is_kerror)(res))
VG_(unmap_range)((Addr)start, length);
return VG_(is_kerror)(res) ? -1 : 0;
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 23:48:02
|
CVS commit by fitzhardinge:
Don't print prediction info for branches if we're not generating it.
M +3 -0 vg_from_ucode.c 1.70
--- valgrind/coregrind/vg_from_ucode.c #1.69:1.70
@@ -93,4 +93,7 @@ static JumpPred static_pred(Condcode con
static const Char *predstr(JumpPred p)
{
+ if (!VG_(clo_branchpred))
+ return "";
+
switch(p) {
default:
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 21:56:36
|
CVS commit by fitzhardinge:
mmap/munmap exerciser test
A map_unmap.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A map_unmap.stderr.exp 1.1
A map_unmap.stdout.exp 1.1
A map_unmap.vgtest 1.1
M +3 -1 Makefile.am 1.18
--- valgrind/none/tests/Makefile.am #1.17:1.18
@@ -23,4 +23,5 @@
fucomip.stderr.exp fucomip.vgtest \
gxx304.stderr.exp gxx304.vgtest \
+ map_unmap.stdout.exp map_unmap.vgtest \
munmap_exe.stderr.exp munmap_exe.vgtest \
pth_blockedsig.stderr.exp \
@@ -42,5 +43,5 @@
args bitfield1 bt_everything bt_literal coolo_strlen \
cpuid dastest discard floored fork fpu_lazy_eflags \
- fucomip munmap_exe rcl_assert \
+ fucomip munmap_exe map_unmap rcl_assert \
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
pth_blockedsig \
@@ -64,4 +65,5 @@
fpu_lazy_eflags_SOURCES = fpu_lazy_eflags.c
fucomip_SOURCES = fucomip.c
+map_unmap_SOURCES = map_unmap.c
munmap_exe_SOURCES = munmap_exe.c
rcl_assert_SOURCES = rcl_assert.S
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 17:21:15
|
On Fri, 2003-12-19 at 02:34, Josef Weidendorfer wrote: > Isn't there a way in the future to translate FP/SSE instructions which access > memory to also use CLOAD/CSTORE? At the moment, FP memory operations are done with FPU_R/FPU_W; MMX and SSE have equivalent Uops. I think it's unlikely we'll start pulling those instructions apart to the extent that we'll end up generating LOAD/STORE for them. But it only matters if a tool actually wants to use FP/MMX/SSE as part of its instrumentation. > PS: Can you supply the following patch to let --tracegen start at BB #0 ? Done. J |
|
From: Jeremy F. <je...@go...> - 2003-12-19 17:18:34
|
CVS commit by fitzhardinge:
Make --trace-codegen start printing from the first basic block, rather
than the second.
M +1 -1 vg_translate.c 1.65
--- valgrind/coregrind/vg_translate.c #1.64:1.65
@@ -2387,5 +2387,5 @@ void VG_(translate) ( /*IN*/ ThreadId t
before --trace-codegen= style printing takes effect. */
notrace_until_done
- = VG_(overall_in_count) > notrace_until_limit;
+ = VG_(overall_in_count) >= notrace_until_limit;
seg = VG_(find_segment)(orig_addr);
|
|
From: Josef W. <Jos...@gm...> - 2003-12-19 10:34:12
|
On Friday 19 December 2003 01:26, Jeremy Fitzhardinge wrote:
> On Thu, 2003-12-18 at 12:12, Josef Weidendorfer wrote:
> > On Thursday 18 December 2003 19:17, Josef Weidendorfer wrote:
> > > Where should I allocate space for this flag?
> > > Or better: How to get rid of the permission check, i.e. the "%fs:"
> > > segment?
> > * We add LOAD/STORE variants that explicitly do no bound checks, which
> > can be used by tools.
>
> I was thinking of adding CSTORE and CLOAD Uops (meaning either Checked
> or Client), so that LOAD and STORE can be used on any address.
Seems to be a good idea.
> I wonder if tools will ever want to generate FP/SSE instructions? At
> the moment, they're always checked too.
Isn't there a way in the future to translate FP/SSE instructions which access
memory to also use CLOAD/CSTORE?
> > 1171 done_this_time = (Int)dispatch_ctr_SAVED - (Int)VG(dispatch_ctr)-1;
> > 1172 vg_assert(done_this_time >= 0);
> ...
Strange. I can't reproduce the failed assertion at the moment ;-(
Josef
PS: Can you supply the following patch to let --tracegen start at BB #0 ?
--- vg_translate.c 18 Dec 2003 09:06:08 -0000 1.64
+++ vg_translate.c 19 Dec 2003 10:32:58 -0000
@@ -2386,7 +2386,7 @@
notrace_until_limit to be the number of translations to be made
before --trace-codegen= style printing takes effect. */
notrace_until_done
- = VG_(overall_in_count) > notrace_until_limit;
+ = VG_(overall_in_count) >= notrace_until_limit;
seg = VG_(find_segment)(orig_addr);
|
|
From: Tom H. <th...@cy...> - 2003-12-19 09:27:31
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2003-12-18 at 23:19, Tom Hughes wrote:
>> In message <107...@ix...>
>> Jeremy Fitzhardinge <je...@go...> wrote:
>>
>> > Hm. There's two possibilities: one is that the mmap syscall itself
>> > failed; the other is that VG_(find_map_space) failed to return some
>> > space. Could you put some debug prints in there to see which case is
>> > occurring, and if its mmap, what the error return is? It seems there
>> > should be plenty of space in the address space for your mapping.
>>
>> It's the call to VG_(find_map_space) at the top of VG_(mmap) that
>> is failing.
>
> I wonder if it's getting confused by all the mmap/munmap calls. This
> should affect a client process which does lots of mmap/munmap calls
> too. I'll have a look. Could you file a bug?
Done as 70827.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 08:23:22
|
On Thu, 2003-12-18 at 23:19, Tom Hughes wrote: > In message <107...@ix...> > Jeremy Fitzhardinge <je...@go...> wrote: > > > Hm. There's two possibilities: one is that the mmap syscall itself > > failed; the other is that VG_(find_map_space) failed to return some > > space. Could you put some debug prints in there to see which case is > > occurring, and if its mmap, what the error return is? It seems there > > should be plenty of space in the address space for your mapping. > > It's the call to VG_(find_map_space) at the top of VG_(mmap) that > is failing. I wonder if it's getting confused by all the mmap/munmap calls. This should affect a client process which does lots of mmap/munmap calls too. I'll have a look. Could you file a bug? J |
|
From: Tom H. <th...@cy...> - 2003-12-19 07:19:05
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Hm. There's two possibilities: one is that the mmap syscall itself
> failed; the other is that VG_(find_map_space) failed to return some
> space. Could you put some debug prints in there to see which case is
> occurring, and if its mmap, what the error return is? It seems there
> should be plenty of space in the address space for your mapping.
It's the call to VG_(find_map_space) at the top of VG_(mmap) that
is failing.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 00:35:53
|
CVS commit by fitzhardinge:
Also remove vgpreload_*.so from LD_PRELOAD when we're not tracing
children.
M +3 -0 vg_syscalls.c 1.71
--- valgrind/coregrind/vg_syscalls.c #1.70:1.71
@@ -1690,4 +1690,7 @@ PRE(execve)
VG_(mash_colon_env)(ld_preload_str, buf);
+ VG_(sprintf)(buf, "%s*/vgpreload_*.so", VG_(libdir));
+ VG_(mash_colon_env)(ld_preload_str, buf);
+
VG_(sprintf)(buf, "%s*", VG_(libdir));
VG_(mash_colon_env)(ld_library_path_str, buf);
|
|
From: Jeremy F. <je...@go...> - 2003-12-19 00:27:49
|
On Thu, 2003-12-18 at 02:32, Tom Hughes wrote: > In message <yek...@au...> > Tom Hughes <th...@cy...> wrote: > > > In message <107...@ix...> > > Jeremy Fitzhardinge <je...@go...> wrote: > > > >> On Thu, 2003-12-18 at 00:24, Tom Hughes wrote: > > > >>> No. It was looking at the symbol tables and was managing to map about > >>> half the libraries then reporting mmap failed for the rest. As I increased > >>> that number it gradually reported fewer and fewer failures. > >> > >> Hm. I'm a bit confused. Can you look at what's mapped at the time it > >> fails? > > > > I'll have a look. > > You are quite right that none of our code is mapped in valgrind's part > of the address space when the mmap fails. They are mapped in the client > part of course, but that shouldn't matter. > > I stopped valgrind in the debugger at the point where the mmap has > just failed, and the resulting map is attached. The stack trace at > that point looks like this: Hm. There's two possibilities: one is that the mmap syscall itself failed; the other is that VG_(find_map_space) failed to return some space. Could you put some debug prints in there to see which case is occurring, and if its mmap, what the error return is? It seems there should be plenty of space in the address space for your mapping. J |
|
From: Jeremy F. <je...@go...> - 2003-12-19 00:26:07
|
On Thu, 2003-12-18 at 12:12, Josef Weidendorfer wrote: > On Thursday 18 December 2003 19:17, Josef Weidendorfer wrote: > > Where should I allocate space for this flag? > > Or better: How to get rid of the permission check, i.e. the "%fs:" segment? > > Followup: > Of course, with --pointercheck=no, I can avoid the %fs prefix. But in this > case, this should be avoided even with --pointercheck=yes, as this is a > STORE instruction generated by the tool. > As LOAD/STORE always does a bound check, there are 3 possibilities: > * I add an extended UCode for this, > * We add LOAD/STORE variants that explicitly do no bound checks, which > can be used by tools. I was thinking of adding CSTORE and CLOAD Uops (meaning either Checked or Client), so that LOAD and STORE can be used on any address. > * Add a flag to LOAD/STORE if a boundcheck should explicitly avoided. This is an option too, but it seems to be a significant enough difference to allocate a Uop for it. I wonder if tools will ever want to generate FP/SSE instructions? At the moment, they're always checked too. > 1171 done_this_time = (Int)dispatch_ctr_SAVED - (Int)VG_(dispatch_ctr) -1; > 1172 vg_assert(done_this_time >= 0); > > done_this_time should be the number of BB executed in the inner loop, isn't > it? But why the "-1" ? Somehow with "--pointercheck=no", done_this_time can > be -1 the first time, and thus the assertion failed. > So I simply removed the "-1". I think that assert fails if it didn't run even one basic block. That could be seen as a problem because you're not making any progress on your program. But I don't really know what the rationale for the assert is. However, it looks to me like that's a secondary symptom of some other problem. I assume this only happens with your tool, and not the rest. Can you see why it would be exiting the basic block early? Does --trace-signals=yes show any signals being delivered? > Now I get another SEGFAULT crash. Using gdb, I found out that in vg_dispatch.S > there is a check for clo_checkpointer,assuming a integer type, but Bool is a > "unsigned char". Change the 2 checks, e.g. the first check to > > movb VG_(clo_pointercheck), %al > testb %al,%al > > , and valgrind runs fine with --pointercheck=no. > Even my skin runs fine now. That's a bit embarrassing. |
|
From: Jeremy F. <je...@go...> - 2003-12-19 00:24:24
|
CVS commit by fitzhardinge:
VG_(clo_pointercheck) is a Bool, which is a byte.
M +4 -4 vg_dispatch.S 1.14
--- valgrind/coregrind/vg_dispatch.S #1.13:1.14
@@ -78,6 +78,6 @@
/* check to see if we're doing pointer checking */
- movl VG_(clo_pointercheck), %eax
- testl %eax,%eax
+ movb VG_(clo_pointercheck), %al
+ testb %al,%al
jz 1f
@@ -148,6 +148,6 @@
run_innerloop_exit:
- movl VG_(clo_pointercheck), %ebx
- testl %ebx,%ebx
+ movb VG_(clo_pointercheck), %bl
+ testb %bl,%bl
jz 1f
|
|
From: Josef W. <Jos...@gm...> - 2003-12-18 20:12:22
|
On Thursday 18 December 2003 19:17, Josef Weidendorfer wrote:
> Where should I allocate space for this flag?
> Or better: How to get rid of the permission check, i.e. the "%fs:" segment?
Followup:
Of course, with --pointercheck=no, I can avoid the %fs prefix. But in this
case, this should be avoided even with --pointercheck=yes, as this is a
STORE instruction generated by the tool.
As LOAD/STORE always does a bound check, there are 3 possibilities:
* I add an extended UCode for this,
* We add LOAD/STORE variants that explicitly do no bound checks, which
can be used by tools.
* Add a flag to LOAD/STORE if a boundcheck should explicitly avoided.
I got a crash when I use valgrind with --pointercheck=no. This has nothing to
do with my tool.
E.g. a valgrind --tool=none --pointercheck=no gives me:
================================================
==12818== For more details, rerun with: -v
==12818==
valgrind: vg_scheduler.c:1172 (vgPlain_scheduler): Assertion `done_this_time
>= 0' failed.
==12818== at 0xB8029A61: vgPlain_skin_assert_fail (vg_mylibc.c:1161)
==12818== by 0xB8029A60: assert_fail (vg_mylibc.c:1157)
==12818== by 0xB8029A9E: vgPlain_core_assert_fail (vg_mylibc.c:1168)
==12818== by 0xB800EECC: vgPlain_scheduler (vg_scheduler.c:1216)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==12818== at 0x81000C10: (within /lib/ld-2.3.2.so)
==================================================
That's before the first BB is executed. Looking at vg_scheduler.c:
1171 done_this_time = (Int)dispatch_ctr_SAVED - (Int)VG_(dispatch_ctr) -1;
1172 vg_assert(done_this_time >= 0);
done_this_time should be the number of BB executed in the inner loop, isn't
it? But why the "-1" ? Somehow with "--pointercheck=no", done_this_time can
be -1 the first time, and thus the assertion failed.
So I simply removed the "-1".
Now I get another SEGFAULT crash. Using gdb, I found out that in vg_dispatch.S
there is a check for clo_checkpointer,assuming a integer type, but Bool is a
"unsigned char". Change the 2 checks, e.g. the first check to
movb VG_(clo_pointercheck), %al
testb %al,%al
, and valgrind runs fine with --pointercheck=no.
Even my skin runs fine now.
Cheers,
Josef
|
|
From: Josef W. <Jos...@gm...> - 2003-12-18 18:17:30
|
On Thursday 18 December 2003 02:06, Jeremy Fitzhardinge wrote:
> Eh, are you saying that the --trace-codegen=10001 output only starts
> after 0x81000D10? I can't see any way in which can not print for early
I found the culprit. Tracegen output started at BB 1, not at BB 0. Patch:
==================================================
--- vg_translate.c 18 Dec 2003 09:06:08 -0000 1.64
+++ vg_translate.c 18 Dec 2003 17:29:59 -0000
@@ -2386,7 +2386,7 @@ void VG_(translate) ( /*IN*/ ThreadId t
notrace_until_limit to be the number of translations to be made
before --trace-codegen= style printing takes effect. */
notrace_until_done
- = VG_(overall_in_count) > notrace_until_limit;
+ = VG_(overall_in_count) >= notrace_until_limit;
seg = VG_(find_segment)(orig_addr);
====================================================
I attached the output of "valgrind --skin=calltree --trace-codegen=10101 ls".
Using the debugger, I found out the place of the SEGFAULT at 0xb874d054,
in the translation of the first basic block. Disassembled with GDB:
...
Dump of assembler code from 0xb874d040 to 0xb874d060:
0xb874d040: mov $0x81000c17,%esi
0xb874d045: mov %edx,%edi
0xb874d047: mov %esi,%fs:(%edx)
0xb874d04a: mov $0xb018eb0c,%eax
0xb874d04f: mov $0x1,%ebx
0xb874d054: mov %ebx,%fs:(%eax)
0xb874d057: mov $0x68,%eax
0xb874d05c: mov %edi,%edx
0xb874d05e: call *0x30(%ebp)
...
Address 0xb874d054 corresponds to Offset 72 in the translated version (from
the attachment):
14: MOVL $0x1, %ebx [ab---D]
67: BB 01 00 00 00
movl $0x1, %ebx
15: STL %ebx, (%eax) [-----D]
72: 64 89 18
movl %ebx, (%eax)
Here, value 1 is a flag I write into a global variable of my skin/tool.
Obviously, this goes wrong as the client has no right to write into valgrind's
space (?). The flag is to be used in a helper called by the translation of the
next basic block.
Where should I allocate space for this flag?
Or better: How to get rid of the permission check, i.e. the "%fs:" segment?
Josef
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 18:02:33
|
On Thu, 2003-12-18 at 09:09, Tom Hughes wrote: > Attached is a patch to fix this. Oops. Thanks. J |
|
From: Tom H. <th...@cy...> - 2003-12-18 17:10:32
|
In message <1071540160.20064.65.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> 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).
I've found another problem - if you fork and exec then it removes
the vg_inject.so entry from LD_PRELOAD but not any vgpreload_xxx.so
entry that the current tool may have added, so if you're using
memcheck you wind up with a very oddly broken malloc in the child
process ;-)
Attached is a patch to fix this.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-12-18 10:05:10
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2003-12-18 at 00:24, Tom Hughes wrote:
>> It gives the kernel a pointer to a pid_t which in which it should
>> store the current thread's tid whenever it feels like it. In this
>> case ld.so was actually passing NULL as the argument so it was in
>> fact turning off this functionality.
>
> So we can just ignore the syscall for now?
I suspect so, because it seemed to work even though it printed a
warning about the unimplemented system call.
>> No. It was looking at the symbol tables and was managing to map about
>> half the libraries then reporting mmap failed for the rest. As I increased
>> that number it gradually reported fewer and fewer failures.
>
> Hm. I'm a bit confused. Can you look at what's mapped at the time it
> fails?
I'll have a look.
>> At 4 and 5, after stdin/out/err and my valgrind log fd which is 3:
>
> That was actually a bug in your patch to set VG_(max_fds) dynamically -
> it was trying to use VG_(safe_fd) before you'd initialized
> VG_(max_fds). I just checked in a fix.
Ah right. I'd forgotten I had some of my patches applied ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:09:25
|
CVS commit by fitzhardinge: Sigh. Add the test files. A yield.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A yield.stderr.exp 1.1 A yield.stdout.exp 1.1 A yield.vgtest 1.1 |
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:06:42
|
CVS commit by fitzhardinge:
Make rep; nop (pause) yield the thread. Based on a patch by Tom Hughes;
I added a test case and cleaned up vg_dispatch.S while I was about it.
CCMAIL: 695...@bu...
M +1 -0 coregrind/vg_constants.h 1.14
M +2 -21 coregrind/vg_dispatch.S 1.13
M +3 -0 coregrind/vg_from_ucode.c 1.69
M +10 -0 coregrind/vg_scheduler.c 1.134
M +5 -1 coregrind/vg_to_ucode.c 1.116
M +1 -0 coregrind/vg_translate.c 1.64
M +2 -1 include/vg_skin.h.base 1.4
M +5 -2 none/tests/Makefile.am 1.17
--- valgrind/coregrind/vg_constants.h #1.13:1.14
@@ -49,4 +49,5 @@
#define VG_TRC_EBP_JMP_SYSCALL 19 /* EBP and TRC */
#define VG_TRC_EBP_JMP_CLIENTREQ 23 /* EBP and TRC */
+#define VG_TRC_EBP_JMP_YIELD 27 /* EBP and TRC */
#define VG_TRC_INNER_FASTMISS 31 /* TRC only; means fast-cache miss. */
--- valgrind/coregrind/vg_dispatch.S #1.12:1.13
@@ -170,30 +170,11 @@
dispatch_exceptional:
/* this is jumped to only, not fallen-through from above */
- cmpl $VG_TRC_EBP_JMP_SYSCALL, %ebp
- jz dispatch_syscall
- cmpl $VG_TRC_EBP_JMP_CLIENTREQ, %ebp
- jz dispatch_clientreq
cmpl $VG_TRC_INNER_COUNTERZERO, %ebp
jz counter_is_zero
-
- /* ebp has an invalid value ... crap out. */
- pushl $panic_msg_ebp
- call VG_(core_panic)
- /* (never returns) */
-dispatch_syscall:
- /* save %eax in %EIP and defer to sched */
- movl $VG_(baseBlock), %ebp
- movl VGOFF_(m_eip), %esi
- movl %eax, (%ebp, %esi, 4)
- movl $VG_TRC_EBP_JMP_SYSCALL, %eax
- jmp run_innerloop_exit
-
-dispatch_clientreq:
/* save %eax in %EIP and defer to sched */
- movl $VG_(baseBlock), %ebp
movl VGOFF_(m_eip), %esi
- movl %eax, (%ebp, %esi, 4)
- movl $VG_TRC_EBP_JMP_CLIENTREQ, %eax
+ movl %eax, VG_(baseBlock)(,%esi, 4)
+ movl %ebp, %eax
jmp run_innerloop_exit
--- valgrind/coregrind/vg_from_ucode.c #1.68:1.69
@@ -2550,4 +2550,7 @@ static void load_ebp_from_JmpKind ( JmpK
VG_(emit_movv_lit_reg) ( 4, VG_TRC_EBP_JMP_CLIENTREQ, R_EBP );
break;
+ case JmpYield:
+ VG_(emit_movv_lit_reg) ( 4, VG_TRC_EBP_JMP_YIELD, R_EBP );
+ break;
default:
VG_(core_panic)("load_ebp_from_JmpKind");
--- valgrind/coregrind/vg_scheduler.c #1.133:1.134
@@ -248,4 +248,5 @@ Char* name_of_sched_event ( UInt event )
case VG_TRC_EBP_JMP_SYSCALL: return "SYSCALL";
case VG_TRC_EBP_JMP_CLIENTREQ: return "CLIENTREQ";
+ case VG_TRC_EBP_JMP_YIELD: return "YIELD";
case VG_TRC_INNER_COUNTERZERO: return "COUNTERZERO";
case VG_TRC_INNER_FASTMISS: return "FASTMISS";
@@ -1187,4 +1188,13 @@ VgSchedReturnCode VG_(scheduler) ( void
switch (trc) {
+ case VG_TRC_EBP_JMP_YIELD:
+ /* Explicit yield. Let a new thread be scheduled,
+ simply by doing nothing, causing us to arrive back at
+ Phase 1. */
+ if (VG_(bbs_to_go) == 0) {
+ goto debug_stop;
+ }
+ break;
+
case VG_TRC_INNER_COUNTERZERO:
/* Timeslice is out. Let a new thread be scheduled,
--- valgrind/coregrind/vg_to_ucode.c #1.115:1.116
@@ -5556,5 +5556,9 @@ static Addr disInstr ( UCodeBlock* cb, A
if (abyte == 0x90) { /* REP NOP (PAUSE) */
if (dis) VG_(printf)("rep nop (P4 pause)\n");
- /* do nothing; apparently a hint to the P4 re spin-wait loop */
+ uInstr1(cb, JMP, 0, Literal, 0);
+ uLiteral(cb, eip);
+ uCond(cb, CondAlways);
+ LAST_UINSTR(cb).jmpkind = JmpYield;
+ *isEnd = True;
}
else {
--- valgrind/coregrind/vg_translate.c #1.63:1.64
@@ -1134,4 +1134,5 @@ void pp_UInstrWorker ( Int instrNo, UIns
case JmpSyscall: VG_(printf)("-sys"); break;
case JmpClientReq: VG_(printf)("-cli"); break;
+ case JmpYield: VG_(printf)("-yld"); break;
default: break;
}
--- valgrind/include/vg_skin.h.base #1.3:1.4
@@ -877,5 +877,6 @@
JmpRet=2, /* jump due to an x86 ret insn */
JmpSyscall=3, /* do a system call, then jump */
- JmpClientReq=4 /* do a client request, then jump */
+ JmpClientReq=4,/* do a client request, then jump */
+ JmpYield=5 /* do a yield, then jump */
}
JmpKind;
--- valgrind/none/tests/Makefile.am #1.16:1.17
@@ -36,5 +36,6 @@
shortpush.stderr.exp shortpush.vgtest \
shorts.stderr.exp shorts.vgtest \
- smc1.stderr.exp smc1.stdout.exp smc1.vgtest
+ smc1.stderr.exp smc1.stdout.exp smc1.vgtest \
+ yield.stdout.exp yield.vgtest
check_PROGRAMS = \
@@ -44,5 +45,5 @@
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
pth_blockedsig \
- coolo_sigaction gxx304
+ coolo_sigaction gxx304 yield
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -g -I$(top_srcdir)/include
@@ -73,4 +74,6 @@
shortpush_SOURCES = shortpush.c
shorts_SOURCES = shorts.c
+yield_SOURCES = yield.c
+yield_LDADD = -lpthread
# pthread C ones
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:03:40
|
On Thu, 2003-12-18 at 00:24, Tom Hughes wrote: > It gives the kernel a pointer to a pid_t which in which it should > store the current thread's tid whenever it feels like it. In this > case ld.so was actually passing NULL as the argument so it was in > fact turning off this functionality. So we can just ignore the syscall for now? > No. It was looking at the symbol tables and was managing to map about > half the libraries then reporting mmap failed for the rest. As I increased > that number it gradually reported fewer and fewer failures. Hm. I'm a bit confused. Can you look at what's mapped at the time it fails? > >> I noticed that if you track FD leaks then both /usr/bin/valgrind and > >> the client executable are reported as leaks. > > > > That shouldn't be. What fds is it finding them at? > > At 4 and 5, after stdin/out/err and my valgrind log fd which is 3: That was actually a bug in your patch to set VG_(max_fds) dynamically - it was trying to use VG_(safe_fd) before you'd initialized VG_(max_fds). I just checked in a fix. J |