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
(16) |
2
(16) |
3
(17) |
|
4
(14) |
5
(16) |
6
(4) |
7
(18) |
8
(24) |
9
(19) |
10
(8) |
|
11
(6) |
12
(4) |
13
|
14
|
15
(1) |
16
(15) |
17
(13) |
|
18
(16) |
19
(11) |
20
(18) |
21
(6) |
22
(4) |
23
(15) |
24
(15) |
|
25
(22) |
26
(17) |
27
(18) |
28
(2) |
29
(16) |
30
(8) |
|
|
From: John R. <jr...@bi...> - 2012-11-30 17:43:40
|
On 11/30/2012 07:47 AM, Julian Seward wrote: > The difficulty is that "set PC to some new value but don't change the > link register" usually, but not always, indicates a non-call. In > particular, if we are doing a tail call then there will simply be a jump > to the start of the new function (or this one, if recursive), which > is no different from a conditional branch back to a loop that starts > at the beginning of this function. > > So the presence/absence of writing the link register can't be used to > reliably distinguish the call/non-call cases. But if neither side makes any provision for instantiating a new activation record, then that is a non-CALL. If the link register is not read and if the stack pointer [or, the head of the chain of activation records] is not read and written, then it is safe to classify the transfer as a non-CALL. -- |
|
From: Petar J. <mip...@gm...> - 2012-11-30 17:33:33
|
> I'm not sure I understand what you mean. Chaining just makes it cheaper > to get from one block to the next. It does not change the order in which > the blocks are visited. > Anyway .. not directly relevant. Not directly relevant, just to make myself clear - we did saw one of the blocks not being chained (#3, see the first email), and that may have something to do with that block marked as T_NoRedir. Have not analyzed that further. > The difficulty is that "set PC to some new value but don't change the > link register" usually, but not always, indicates a non-call. True in general, but the functions we replace are in shared libraries, and there are some restrictions for them, as far as PIC/Linux is in question. > In > particular, if we are doing a tail call then there will simply be a jump > to the start of the new function (or this one, if recursive), which > is no different from a conditional branch back to a loop that starts > at the beginning of this function. Recursive tail call does not necessarily jump to the start of the function. So we may be already missing these calls (if there were any in functions that we replace). Also, some optimizations are not possible for shared libraries, since (i.e. calls to) functions may be overridden. Petar |
|
From: Julian S. <js...@ac...> - 2012-11-30 15:56:26
|
On Friday, November 30, 2012, Petar Jovanovic wrote: > It could happen there as well, but chaining made it worse as it removed > a block with LL. I'm not sure I understand what you mean. Chaining just makes it cheaper to get from one block to the next. It does not change the order in which the blocks are visited. Anyway .. not directly relevant. > If we introduce a change which would prevent redirections coming from > branches and jumps (in contrast to branch-and-link and jump-and-link), > would not that work for ARM as well? It is true that "write PC+4 to the link register and set PC to some new value" clearly indicates a call. No problems there. The difficulty is that "set PC to some new value but don't change the link register" usually, but not always, indicates a non-call. In particular, if we are doing a tail call then there will simply be a jump to the start of the new function (or this one, if recursive), which is no different from a conditional branch back to a loop that starts at the beginning of this function. So the presence/absence of writing the link register can't be used to reliably distinguish the call/non-call cases. J |
|
From: Petar J. <mip...@gm...> - 2012-11-30 15:02:45
|
> It is unrelated to chaining -- only the redirection is a > problem. It could happen also in a pre-chaining version (eg, 3.7.x) It could happen there as well, but chaining made it worse as it removed a block with LL. > One possibility > is to add some kind of hack that says that all targets reached from > conditional branches are not to be redirected. That would fix this > case, but could cause potential other failures on, in particular, > conditional calls on ARM to a redirected function. If we introduce a change which would prevent redirections coming from branches and jumps (in contrast to branch-and-link and jump-and-link), would not that work for ARM as well? > Also, there is an ambiguity about the meaning of a jump back to the start > of a function (in general). Is this just a loop back edge, that we do not > want to redirect? Or is it a tail-recursive call to the function, that > we do want to recursively redirect (so the recursive call goes via > a recursive invokation of the wrapper) ? There's no easy way to distinguish > these cases at the machine code level. True, but are we aware of any function of interest that makes use of tail- recursive calls? Petar |
|
From: Florian K. <br...@ac...> - 2012-11-30 14:06:23
|
On 11/30/2012 08:19 AM, Julian Seward wrote: > > Wow! I didn't notice that before. May well be the first time this > has ever happened :) > For history buffs: http://article.gmane.org/gmane.comp.debugging.valgrind.devel/20945/match=hooray No clue about other platforms... Florian |
|
From: Julian S. <js...@ac...> - 2012-11-30 13:28:11
|
Wow! I didn't notice that before. May well be the first time this has ever happened :) J On Friday, November 09, 2012, Florian Krohm wrote: > Hooray ! > > On 11/09/2012 08:35 AM, Christian Borntraeger wrote: > > valgrind revision: 13116 > > VEX revision: 2559 > > C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision > > 152973] Assembler: GNU assembler (GNU Binutils; SUSE Linux > > Enterprise 11) 2.21.1 C library: GNU C Library stable release > > version 2.11.3 (20110527) uname -mrs: Linux 3.0.42-0.7-default > > s390x > > Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP2 > > (s390x) - Kernel %r (%t). > > > > Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 > > on z196 (s390x) ) Started at 2012-11-09 14:07:01 CET > > Ended at 2012-11-09 14:35:52 CET > > Results differ from 24 hours ago > > > > Checking out valgrind source tree ... done > > Configuring valgrind ... done > > Building valgrind ... done > > Running regression tests ... done > > > > Regression test results follow > > > > == 609 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 > > stdoutB failures, 0 post failures == > > > > ================================================= > > == Results from 24 hours ago == > > ================================================= > > > > Checking out valgrind source tree ... done > > Configuring valgrind ... done > > Building valgrind ... done > > Running regression tests ... failed > > > > Regression test results follow > > > > == 608 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 > > stdoutB failures, 0 post failures == > > > > > > ================================================= > > == Difference between 24 hours ago and now == > > ================================================= > > > > *** old.short 2012-11-09 14:21:36.000000000 +0100 > > --- new.short 2012-11-09 14:35:52.000000000 +0100 > > *************** > > *** 4,6 **** > > > > Building valgrind ... done > > > > ! Running regression tests ... failed > > > > --- 4,6 ---- > > > > Building valgrind ... done > > > > ! Running regression tests ... done > > > > *************** > > *** 8,10 **** > > > > ! == 608 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, > > 0 stdoutB failures, 0 post failures == > > > > --- 8,10 ---- > > > > ! == 609 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, > > 0 stdoutB failures, 0 post failures == > > > > > > > > > > ------------------------------------------------------------------------- > > ----- Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_nov > > > > > > > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > --------------------------------------------------------------------------- > --- Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Josef W. <Jos...@gm...> - 2012-11-30 13:23:34
|
Am 29.11.2012 15:52, schrieb Petar Jovanovic: > hi everyone, > > here is another issue related to LL/SC, MIPS and Valgrind. The issue happens in > DRD in pthread_spin_lock related tests (annotate_spinlock, pth_spinlock). > > On MIPS, pthread_spin_lock looks like this: > > 0000d130 <pthread_spin_lock>: > 0x048869a0: ll a2,0(a0) > 0x048869a4: bnez a2,0x48869a0 > 0x048869a8: li a1,1 > 0x048869ac: sc a1,0(a0) > 0x048869b0: beqz a1,0x48869a0 > 0x048869b4: move at,at > > As you can see, branch after SC will go directly to the start of the function. > However, V will not jump to the begging of the block, rather back again to the > wrapper function in drd_pthread_intercepts.c. As far as I remember, doing redirection in a robust way is very tricky. I think you found a buggy corner case which did not happen yet. A solution could be this: for all branches/jumps within the instruction range of a function with redirection, never do a redirection for the function itself. But whether that is easily doable, that is a question for Julian. Josef |
|
From: Julian S. <js...@ac...> - 2012-11-30 13:21:36
|
Petar, I can see what the problem is, but I can't think of a clean way to fix it. It is unrelated to chaining -- only the redirection is a problem. It could happen also in a pre-chaining version (eg, 3.7.x) The problem is that the function redirection system regards all control flow transfers to the label <pthread_spin_lock> (in this example) as something that it must redirect. It cannot distinguish between a transfer from outside the function -- which is what it correctly redirects -- and the two transfers from inside the function (the bnez and beqz) -- which it incorrectly redirects (to the wrapper). In fact I can't think of any good solutions right now. One possibility is to add some kind of hack that says that all targets reached from conditional branches are not to be redirected. That would fix this case, but could cause potential other failures on, in particular, conditional calls on ARM to a redirected function. Another possibility is to guarantee that all control flow transfers that stay within the same function are not subject to redirection. Problem is that this means the behaviour of the simulator becomes dependent on the details of what is in the symbol table of libpthread.so (in this example). For example, if the symbol table correctly describes both the start address and size of pthread_spin_lock, then this heuristic will work. But if the size field is missing or too small, it may be that the bnez / beqz are not recognised as being "inside" the function, and so this heuristic fails. Also, there is an ambiguity about the meaning of a jump back to the start of a function (in general). Is this just a loop back edge, that we do not want to redirect? Or is it a tail-recursive call to the function, that we do want to recursively redirect (so the recursive call goes via a recursive invokation of the wrapper) ? There's no easy way to distinguish these cases at the machine code level. Another possibility (which also doesn't work) is to have a way for a wrapper function to say "I can never be called recursively", so that an apparent recursive redirect attempt (as in this example) is detected and avoided. Problem is that this requires keeping track of the set of currently active wrapper functions in each thread, and correctly clearing them even when a thread longjumps (ugly but possible) or when it switches stacks arbitrarily (more or less impossible to do reliably). So, right now, no .. I can't think of a robust solution. Can you at least file a bug report about this, so it is tracked? J On Thursday, November 29, 2012, Petar Jovanovic wrote: > hi everyone, > > here is another issue related to LL/SC, MIPS and Valgrind. The issue > happens in DRD in pthread_spin_lock related tests (annotate_spinlock, > pth_spinlock). > > On MIPS, pthread_spin_lock looks like this: > > 0000d130 <pthread_spin_lock>: > 0x048869a0: ll a2,0(a0) > 0x048869a4: bnez a2,0x48869a0 > 0x048869a8: li a1,1 > 0x048869ac: sc a1,0(a0) > 0x048869b0: beqz a1,0x48869a0 > 0x048869b4: move at,at > > As you can see, branch after SC will go directly to the start of the > function. However, V will not jump to the begging of the block, rather > back again to the wrapper function in drd_pthread_intercepts.c. V will > chain the translated blocks, and skip the original block with LL as it was > marked T_NoRedir. This will trigger endless loop with SC failing each > time, and subsequent calls to the wrapper function which also changes > stack pointer each time and the test crashes at the end. > > For the test purposes, we recompiled glibc to include an extra NOP at the > start of the function pthread_spin_lock, and then we see no issues. > > So, any ideas how to correct this in a nice way? > > > Regards, > Petar > > LOG: > --24728-- REDIR: 0x48869a0 (pthread_spin_lock) redirected to 0x485384c > (pthread_spin_lock) > ==== SB 1661 (evchecks 18997) [tid 1] 0x485384c pthread_spin_lock > /home/dejan/mnt-rtrkw137/valgrind_tmp/exec/lib/valgrind/vgpreload_drd-mips3 > 2-linux.so+0xe84c ==== SB 1662 (evchecks 18997) [tid 1] 0x48538d8 > pthread_spin_lock+140 > /home/dejan/mnt-rtrkw137/valgrind_tmp/exec/lib/valgrind/vgpreload_drd-mips > 32-linux.so+0xe8d8 ==== SB 1663 (evchecks 18997) [tid 1] 0x48869a0 > pthread_spin_lock > /lib/libpthread-2.11.2.so+0xd9a0 > ==== SB 1663 (evchecks 18997) [tid 1] 0x48869ac pthread_spin_lock+12 > /lib/libpthread-2.11.2.so+0xd9ac > > --------------------------------------------------------------------------- > --- Keep yourself connected to Go Parallel: > VERIFY Test and improve your parallel project with help from experts > and peers. http://goparallel.sourceforge.net > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |