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
(6) |
2
(3) |
3
(2) |
4
(1) |
5
(1) |
6
(6) |
7
(9) |
|
8
(8) |
9
(6) |
10
(13) |
11
(9) |
12
(12) |
13
(6) |
14
(1) |
|
15
(4) |
16
(8) |
17
(15) |
18
(7) |
19
(3) |
20
(11) |
21
(7) |
|
22
(26) |
23
(7) |
24
(4) |
25
(9) |
26
(10) |
27
(13) |
28
(6) |
|
29
(11) |
30
(6) |
31
(8) |
|
|
|
|
|
From: Evgeniy S. <eu...@go...> - 2010-08-04 08:54:09
|
Thanks for the advice! Some comments inline.
On Thu, Jun 3, 2010 at 10:02 AM, Julian Seward <js...@ac...> wrote:
>
> > I've got some success with the following approach. I steal the address of
> > usleep() function from the program with a client request from vgpreload
> > part of the tool, and insert a call to that address during code
> > instrumentation:
> >
> > // put sleep duration in %edi
> > PUT(56) = 0xF4241:I64
> > // put return address on the stack
> > t15 = GET:I64(32)
> > t16 = Sub64(t15,0x8:I64)
> > PUT(32) = t16
> > STle(t16) = 0x405F55:I64
> > // call the stolen usleep()
> > if (1:I1) goto {Call} 0x40A012:I64
> >
> > This code must be placed immediately before an IMark, whose address is
> the
> > return address of the call (0x405FF5 in this case). It also can not be
> > placed at the beginning of an IRSB, because valgrind complains about an
> > unknown PC. This approach is very arch-dependent and does not feel right.
>
> I think this will work, but as you say, it is ugly.
>
> > Is there a simpler way to do this? Is it possible to somehow tell the
> > valgrind scheduler to let the other threads run for a bit (some kind of
> > VG_(sched_yield) or VG_(sleep))?
>
> Yes (I think so .. I tried something like this a couple of months
> back).
>
> Let's suppose X is the client instruction after which you want to
> let other threads run. After the translation of X, finish the
> IRSB, and put a jump to the next instruction. (in the same way
> that the front ends will translate an unconditional branch that
> they don't chase into).
>
It seems that, unless I pass --vex-iropt-level=0, pre-instrumentation
optimization pass can move some instruction side effects past the IMark. For
example, this code:
0xD7DF7F7: movq (%rsi),%rax
------ IMark(0xD7DF7F7, 3) ------
t0 = GET:I64(48)
PUT(0) = LDle:I64(t0)
0xD7DF7FA: leaq 64(%rsp), %rcx
------ IMark(0xD7DF7FA, 5) ------
PUT(168) = 0xD7DF7FA:I64
t1 = Add64(GET:I64(32),0x40:I64)
PUT(8) = t1
..................
is translated to this even before the tool can take a look at it:
------ IMark(0xD7DF7F7, 3) ------
t0 = GET:I64(48)
t58 = LDle:I64(t0)
------ IMark(0xD7DF7FA, 5) ------
t60 = GET:I64(32)
t59 = Add64(t60,0x40:I64)
..............
If the IRSB is finished at 0xD7DF7FA IMark, all effects of the previous
instruction will be lost. Disabling optimization helps, but obviously slows
down execution and still looks fragile. What is the correct way to finish an
IRSB at some point, making sure that all effects of instructions up to that
point have already happened?
Except .. for this jump, mark it as Ijk_Yield, not _Boring.
>
> In scheduler.c find this
>
> case VEX_TRC_JMP_YIELD:
> /* Explicit yield, because this thread is in a spin-lock
> or something. Only let the thread run for a short while
> longer. Because swapping to another thread is expensive,
> we're prepared to let this thread eat a little more CPU
> before swapping to another. That means that short term
> spins waiting for hardware to poke memory won't cause a
> thread swap. */
> if (VG_(dispatch_ctr) > 2000)
> VG_(dispatch_ctr) = 2000;
> break;
>
> change '2000' to '1'
>
> In scheduler.c find this
>
> /* ------------ now we don't have The Lock ------------ */
> ...
> /* ------------ now we do have The Lock ------------ */
>
> in between these two comments add this
>
> VG_(do_syscall0)(__NR_sched_yield);
>
> this should cause the thread to be placed to the back of the run queue
> for threads of this priority, which will allow another thread to run.
>
> but be careful, I think __NR_sched_yield on linux takes a parameter which
> controls its behaviour. Google for that.
>
> add debug printing to make sure this is really behaving as you expect.
> (it's all pretty fragile, but I'm sure i had something like this working
> earlier this year)
>
I've noticed a VG_(vg_yield) function that seems to do exactly what is
needed. Is there a fundamental reason why it can not be used in helper
functions? Is there an assumption somewhere that the_BigLock can not be
released when a block of generated code has started execution and not
finished it yet?
|