You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
(8) |
3
(9) |
4
(6) |
5
(13) |
6
(18) |
7
(2) |
|
8
(1) |
9
(6) |
10
(4) |
11
(6) |
12
(11) |
13
(3) |
14
|
|
15
(4) |
16
(5) |
17
(11) |
18
(3) |
19
(31) |
20
(2) |
21
(5) |
|
22
(3) |
23
(4) |
24
(1) |
25
(4) |
26
(7) |
27
(2) |
28
(6) |
|
29
(2) |
30
(2) |
31
(4) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2005-05-19 11:54:31
|
> On Thursday 19 May 2005 11:32, Tom Hughes wrote: > Wouldn't it be better to do it for any code on the stack? Any code on > the stack is inherently dangerous because it can be invalidated by the > stack pointer moving. > > So just testing for code being in a segment with SF_STACK set might > do as a heuristic. Yes. You're quite right. I'm just trying to figure out how to balance the conflicting demands of (1) self-check as many translations as possible so as to minimise the chances of not catching one of these trampolines vs (2) self-check as few translations as possible so as to minimise the performance hit. > On i386 (32 bit), trampolines have the following properties: > > (1) they are always aligned on 16 byte boundaries > (2) they always consist of the following two instructions: > > mov #STATIC,ecx > jmp FUNCTION That's true, but it's too fragile, as Tom points out. One over- enthusiastic gcc hacker changing this a bit and we're hosed. Self-checking all translations from a stackish segment seems about right. So, what I'm thinking is to calculate a 32-bit CRC of the code and store it in the translation; then rerun the crc for the self-check. Except a CRC is expensive in terms of insns and cache misses (it requires a table). Mark Adler (co-author of gzip) had some other magic checksum scheme that gzip uses, which doesn't require a table and is fast. Maybe use that instead. J |
|
From: Duncan S. <bal...@fr...> - 2005-05-19 10:56:01
|
Hi Julian, the pain is already less!
> Let me see if I understand the landscape correctly.
>
> The problem is that ada (and nested C/C++ fns, with gcc) create small
> bits of code on the stack and then run them. V fails to notice when on
> of these small bits of code gets re-made, and so may wind up using out
> of date translations.
that is my understanding.
> So we can easily enough generate self-checking translations. A problem
> is, since self-checking translations are expensive to run, we want to
> make as few as possible. That means having a good heuristic for deciding
> when to do so. The currently postulated heuristic is to make a self-
> checking translation for code within some small offset of the stack
> pointer. Ideally the heuristic should say "yes" as infrequently as
> possible, but it should also never miss any such cases either.
>
> Is that correct? Any other things I need to take into account?
On i386 (32 bit), trampolines have the following properties:
(1) they are always aligned on 16 byte boundaries
(2) they always consist of the following two instructions:
mov #STATIC,ecx
jmp FUNCTION
I got this from gcc/doc/tm.texi and gcc/config/i386/i386.h.
In gcc/config/i386/i386.c you can find x86_initialize_trampoline
which generates 0xb9 (mov ecx,imm32) and 0xe9 (jmp rel32).
II guess if you look for jumps to 16 byte aligned guys holding
those instructions near the stack pointer, then the number of
false positives will be small. Of course this is gcc specific -
do other compilers do this kind of thing too?
All the best,
Duncan.
|
|
From: Tom H. <to...@co...> - 2005-05-19 10:32:43
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> So we can easily enough generate self-checking translations. A problem
> is, since self-checking translations are expensive to run, we want to
> make as few as possible. That means having a good heuristic for deciding
> when to do so. The currently postulated heuristic is to make a self-
> checking translation for code within some small offset of the stack
> pointer. Ideally the heuristic should say "yes" as infrequently as
> possible, but it should also never miss any such cases either.
Wouldn't it be better to do it for any code on the stack? Any code on
the stack is inherently dangerous because it can be invalidated by the
stack pointer moving.
So just testing for code being in a segment with SF_STACK set might
do as a heuristic.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-05-19 10:17:45
|
> > I guess Ada-interoperability is a dark corner, then :) You're only the > > second person I recall being stung by this. > > The pain is real though... Person number two humbly asks if anything > can be done. Ok, I'll think about what's needed to implement this. Let me see if I understand the landscape correctly. The problem is that ada (and nested C/C++ fns, with gcc) create small bits of code on the stack and then run them. V fails to notice when on of these small bits of code gets re-made, and so may wind up using out of date translations. So we can easily enough generate self-checking translations. A problem is, since self-checking translations are expensive to run, we want to make as few as possible. That means having a good heuristic for deciding when to do so. The currently postulated heuristic is to make a self- checking translation for code within some small offset of the stack pointer. Ideally the heuristic should say "yes" as infrequently as possible, but it should also never miss any such cases either. Is that correct? Any other things I need to take into account? J |
|
From: Duncan S. <bal...@fr...> - 2005-05-19 08:24:19
|
> >> Right. Unfortunately you've hit a dark corner of Valgrind that doesn't > >> work very well. > > > > By the way, local procedures are much more widely used in a language > > like Ada, than in C. > > I guess Ada-interoperability is a dark corner, then :) You're only the > second person I recall being stung by this. The pain is real though... Person number two humbly asks if anything can be done. > > As a data point, I ran all the ACATS tests (see the gcc testsuite/ada > > directory) under valgrind, and the majority of failures were spurious, > > coming from the trampoline problem. On the other hand, there are about > > 1800 tests, and only about 50 triggered the trampoline problem (I don't > > recall the exact number), so it's not that common either. > > That's good to know; thanks for the data point. It's going to get worse though - the latest language revision adds a container library that pretty much requires taking pointers to local subroutines. That's the reason this kind of thing is spreading through my code right now. This will also be the case for other Ada users. I know we are not so numerous, but we certainly exist :) Best wishes, Duncan. |