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
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2002-12-10 23:28:07
|
(mozilla-1.2.1 was looping with memcheck ...) > > It all _looks_ plausible. I'm a bit mystified. You sure this j[n]p > > trick in 69- has no strange side-effects? I can't think of any. Perhaps > > this is a red herring. > > Looks OK to me, but its a bit hard to tell without seeing the original > code. > > What happens if you change it back to the popf slow path? Still happen? I dunno; I removed the popf stuff. However, backing out 69- makes it work properly. I identified the original code: 0x40224f10 mov 0x4(%edi),%eax 0x40224f13 mov 0x10(%eax),%eax 0x40224f16 mov %eax,0x4(%edi) 0x40224f19 mov 0x10(%eax),%edx 0x40224f1c mov 0x4(%ecx),%eax 0x40224f1f cmp 0x4(%edx),%eax 0x40224f22 jl 0x40224f10 Attached is the cleaned-up and annotated memcheck translation. The stuff to do with cmp and jl looks OK to me; the %eflags value set by the cmp (simulation) is correctly copied off to safety before the stuff for the jl, and the relevant simd test for JL looks right. So I'm still mystified. One unedifying explaination is that this translation is correct, and the reason it is looping is that some earlier translation has written bogus values into memory, which the above loop is picking up and looping on. I don't fancy chasing that down. I'm going to back out 69- from cvs until we have a clearer picture what's going on. Do shout if you have any ideas at all. It makes me uneasy that I don't know what's going on here. > One possibility I've been thinking about is whether there's any code > which depends on the undefined flags behaviour of instructions. It > would be a (compiler?) bug, but it might change the behaviour of real > programs. Um, that's not good. Should I be concerned? > The simulated CPU will leak lots of real flags into the undefined > flags. The solution would be to add an undef_flags argument to > new_emit, and add a --paranoid-flags=yes|no command line option; > new_emit could then decide whether to fetch the flags or not. A quick > test to see if that's happening in this case is to force new_emit to > always make sure the simulated flags are current before every simulated > instruction. > > At one point I hacked none to "instrument" the code to trash the real > flags between every UInstr. Unfortunately I think I lost this (and it > was a bit of a blight on none's purity). Is there a good existing skin > for this kind of skulduggery? Umm, I'm not sure what you mean by good. Memcheck is probably the most demanding in that nearly every original ucode is preceded by instrumentation which very likely trashes (real) eflags. Is that what you meant? If there's some way in which you could hack a skin to do a stress-test of your flags machinery, that would be very helpful. J |
|
From: Julian S. <js...@ac...> - 2002-12-10 00:25:35
|
Results from this evening's testing of the head: - Works OK on R H 7.2 (it builds, mozilla-1.0, OO-1.0.1 run on all skins) - Ditto R H 7.3, R H 8.0, SuSE 8.1 - After some futzing, got it to build again on R H 6.2 (our oldest supported platform). Two strange things: --skin=cachegrind causes an instant segfault at startup, before anything is printed. It's so quick I wonder if the dynamic linker is crashing. mozilla-1.2.1 (binary .tar.gz build downloaded from mozilla.org) runs OK on nulgrind, addrcheck, but spins after 100 million ish bbs on memcheck, so it draws part of a window and never progresses. This could be a R H 6.2 problem or a virtual CPU problem which only shows up with that 1.2.1 build -- haven't checked on any other distros. I bet its some kinda flag wierdness tho, considering it works ok on some skins. I got a quick trace with gdb and it's definitely in a loop. I'll have a look at it perhaps late tomorrow night; out of time now. Trace is attached. J |