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
(9) |
2
(13) |
3
(3) |
4
(3) |
5
(4) |
|
6
(2) |
7
(4) |
8
(3) |
9
(2) |
10
|
11
|
12
(6) |
|
13
(6) |
14
(1) |
15
(2) |
16
(2) |
17
(2) |
18
|
19
|
|
20
|
21
|
22
(1) |
23
|
24
(2) |
25
(5) |
26
|
|
27
(1) |
28
(8) |
29
(3) |
30
|
|
|
|
|
From: Julian S. <js...@ac...> - 2003-04-28 22:18:36
|
Hi I wonder if anyone can cast any light on the following. I am completely mystified, not to mention stuck. I'm doing stuff to add SSE/SSE2 support. This means changing various fsave/frstor instructions, which move the FPU state back and forth between the simulated and real cpus, into their SSE equivalents, fxsave and fxrstor. The SSE state is larger than the FPU/MMX state so various structures have had their size increased. There is also a 16-byte alignment constraint on addresses in fxsave/fxrstor, so I've ensured that too. Now, I think I've done everything right. Nevertheless, one of my fxrstor's, in vg_syscalls.S, is segfaulting. I have no idea why. It's this fxrstor VG_(m_state_static)+64 (previously of course) frstor VG_(m_state_static)+64 and the address is duly 16-byte aligned, and the memory from that address for 512 bytes (the SSE state size) appears suitably accessible. A few lines earlier there is fxrstor VG_(real_sse_state_saved_over_syscall) and that works fine. Help! I'm stuck. Is there some other magic constraints on fxrstor I need to know about? I read the fine print in the P4 documentation carefully, but I cannot see anything other than the 16-byte-alignment constraint. J |
|
From: Adam G. <ar...@cy...> - 2003-04-28 16:30:17
|
At 17:04 28/04/03 +0100, Julian Seward wrote: >On Monday 28 April 2003 12:39 pm, Adam Gundy wrote: >> Flushing the translation cache using the DISCARD_TRANSLATIONS user request >> doesn't always work - if the code has already been executed, basic blocks >> which chain to the one to be discarded are ignored. >> >> This means that modified code sometimes behaves as if it has not been >> modified! >> >> The attached patch makes VG_(invalidate_translations)() take a flag >> indicating whether basic blocks which chain to the discarded blocks should >> also be discarded. >> >> I did originally _always_ use this behaviour, but it is painfully slow when >> a shared object is unmapped. > >But the thing is, don't we _always_ have to unchain translations when >discarding code, in order that this is ever safe? > >Hmm. Tell me if this logic is OK. > >If some tiny fragment of code is discarded, we have to unchain everything >to make it safe; this is the safe but general case. erk. no - we only have to unchain things that chain directly to that tiny fragment. The problem is the stale 'chain' jumps that are left lying around - when we unchain them, the jumps get set to VG_(patch_me)(), so that if the chain gets called, things get patched up. see VG_(unchain_jumpsite)(). >If a complete .so's text section is munmapped, we can sort-of get away with >just dumping the relevant translations. This is all highly dubious since >it assumes that no translations of code in some other mapped text segment >chain to those in the segment we're discarding. What guarantees that? >I guess it must be the surrounding program logic, which knows not to call >functions in .so's it has munmapped (dlclosed at a higher level). I am >a bit confused here ... the surrounding program logic. I hope. in practice anyone calling a function in a shared object which has been dlclosed() has already been rewarded with a SEGV - they don't need to be using valgrind for that... >I must say I'm not happy about this level of fragileness and didn't realise >V behaved this way by default. How horribly does unchaining trash your >performance? I wonder if there is anything we can do to reduce the cost >of it. unchaining shared objects affects performance _really_ badly. Try changing the False to True in VG_(remove_if_exe_segment)(). valgrind will take 10+ seconds on a fast machine every time a shared object is unloaded. this happens quite a lot on Linux (and even more under WINE)... I tried a few performance enhancements, like trying to batch up the 'unchain' scans, merging multiple basic block regions needing unchaining into single blocks etc. none of it helped very much. the big problem is that although the shared object is a contiguous chunk of memory, the translated basic blocks _aren't_; they're spread all over the translation cache :-( Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Julian S. <js...@ac...> - 2003-04-28 16:04:32
|
On Monday 28 April 2003 12:39 pm, Adam Gundy wrote: > Flushing the translation cache using the DISCARD_TRANSLATIONS user request > doesn't always work - if the code has already been executed, basic blocks > which chain to the one to be discarded are ignored. > > This means that modified code sometimes behaves as if it has not been > modified! > > The attached patch makes VG_(invalidate_translations)() take a flag > indicating whether basic blocks which chain to the discarded blocks should > also be discarded. > > I did originally _always_ use this behaviour, but it is painfully slow when > a shared object is unmapped. But the thing is, don't we _always_ have to unchain translations when discarding code, in order that this is ever safe? Hmm. Tell me if this logic is OK. If some tiny fragment of code is discarded, we have to unchain everything to make it safe; this is the safe but general case. If a complete .so's text section is munmapped, we can sort-of get away with just dumping the relevant translations. This is all highly dubious since it assumes that no translations of code in some other mapped text segment chain to those in the segment we're discarding. What guarantees that? I guess it must be the surrounding program logic, which knows not to call functions in .so's it has munmapped (dlclosed at a higher level). I am a bit confused here ... I must say I'm not happy about this level of fragileness and didn't realise V behaved this way by default. How horribly does unchaining trash your performance? I wonder if there is anything we can do to reduce the cost of it. J |
|
From: Adam G. <ar...@cy...> - 2003-04-28 12:04:23
|
A new version of the patch to valgrind needed to support WINE has been uploaded to Sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46268&atid=445588 It should apply cleanly to current valgrind CVS. This version of the patch will now work with an unmodified WINE CVS version. This is because it now _fully_ implements clone() support - ie it really does create system level threads. Currently only one thread can run at a time, so there are no locking issues in the main valgrind code. To use with WINE, you need to get a CVS checkout of valgrind, then apply the patch using: export CVSROOT=:pserver:ano...@cv...:/cvsroot/valgrind cvs login cvs co valgrind patch -p0 < valgrind-wine.patch.13 then build and install valgrind: autogen.sh ./configure make install Get a CVS checkout of WINE by following the instructions at: http://www.winehq.com/?page=cvs then configure (for debugging) and build: CFLAGS=-g ./configure make depend && make install now you can start looking for bugs in WINE, and bugs in your own (debug) Windows code. Copy any DLLs/EXEs to somewhere WINE can get to them, plus copy any .PDB files that go with them into the same directory. Run WINE under valgrind using eg: valgrind --num-callers=30 --workaround-gcc296-bugs=yes wine notepad.exe or even: valgrind --num-callers=30 --workaround-gcc296-bugs=yes --gdb-attach=yes wine notepad.exe enjoy. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Adam G. <ar...@cy...> - 2003-04-28 11:41:01
|
Flushing the translation cache using the DISCARD_TRANSLATIONS user request doesn't always work - if the code has already been executed, basic blocks which chain to the one to be discarded are ignored. This means that modified code sometimes behaves as if it has not been modified! The attached patch makes VG_(invalidate_translations)() take a flag indicating whether basic blocks which chain to the discarded blocks should also be discarded. I did originally _always_ use this behaviour, but it is painfully slow when a shared object is unmapped. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Adam G. <ar...@cy...> - 2003-04-28 11:35:31
|
there are three places where if a thread switches stack, valgrind doesn't keep its idea of the highest word in the stack in sync. This causes backtraces with only one function in them, and sometimes causes valgrind to quit. The attached patch fixes all three cases. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Adam G. <ar...@cy...> - 2003-04-28 11:32:40
|
When software has been messing with the tty state, sometimes the enter key generates the '\r' carriage return instead of '\n'. Attached patch allows either. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Adam G. <ar...@cy...> - 2003-04-28 11:30:59
|
the attached patch provides implementation for gettid(), and makes set_thread_area() return -ENOSYS (which current code should cope with and fall back to modify_ldt()). Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |