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-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
|