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
(15) |
2
(12) |
3
(11) |
4
(20) |
5
(6) |
|
6
(6) |
7
(7) |
8
(8) |
9
(17) |
10
(25) |
11
(27) |
12
(6) |
|
13
(28) |
14
(16) |
15
(20) |
16
(9) |
17
(26) |
18
(7) |
19
(25) |
|
20
(7) |
21
(18) |
22
(25) |
23
(15) |
24
(21) |
25
(32) |
26
(15) |
|
27
(23) |
28
(33) |
|
|
|
|
|
|
From: Chris J. <ch...@at...> - 2005-02-03 21:17:56
|
> On Thu, 2005-02-03 at 14:33 +1100, Steve Blackburn wrote: > > In Jikes RVM we generate a number of software traps using the INT=20 > > instruction. > > These are int 40 through to int 43. We use these to catch=20 > conditions such as=20 > > array bounds violations, throw control to a signal handler=20 > which then starts our=20 > > (Java) execption handling mechanism. So, yes, we do use=20 > these, and we catch=20 > > them in a regular signal hanler. >=20 > Oh, OK, I see. >=20 > > Perhaps all that needs to be done is for valgrind to implemetn the=20 > > behavior you > > describe above: make it look like a SIGSEGV. >=20 > Right, that's easy. I don't think you can tell from the=20 > signal info alone which int instruction it was, so we can=20 > easily simulate the effect of them all by calling a helper=20 > with, say, INT $99 in it. Hm, need to make sure that all the=20 > VCPU state is up to date at that point, so you can see it=20 > from the signal handler. Do you look at other CPU state from=20 > the handler, or just EIP? Do you expect to be able to=20 > continue after the INT instruction, or does it always raise a=20 > Java exception? I think the breakpoints patch I've posted to this list could be = informative here since it handles INT $3. The same principles could be extended to handle other interrupts. Basically what the patch does is translate the = trap instruction into code to return from the innerloop with a particular TRC value. This value is then caught in VG_(scheduler) which raises a real signal (SIGTRAP in this case). Raising a real signal has the benefit it = can be seen by a debugger. Chris |
|
From: Jeremy F. <je...@go...> - 2005-02-03 04:15:42
|
On Thu, 2005-02-03 at 14:33 +1100, Steve Blackburn wrote: > In Jikes RVM we generate a number of software traps using the INT instruction. > These are int 40 through to int 43. We use these to catch conditions such as > array bounds violations, throw control to a signal handler which then starts our > (Java) execption handling mechanism. So, yes, we do use these, and we catch > them in a regular signal hanler. Oh, OK, I see. > Perhaps all that needs to be done is for valgrind to implemetn the behavior you > describe above: make it look like a SIGSEGV. Right, that's easy. I don't think you can tell from the signal info alone which int instruction it was, so we can easily simulate the effect of them all by calling a helper with, say, INT $99 in it. Hm, need to make sure that all the VCPU state is up to date at that point, so you can see it from the signal handler. Do you look at other CPU state from the handler, or just EIP? Do you expect to be able to continue after the INT instruction, or does it always raise a Java exception? J |
|
From: <js...@ac...> - 2005-02-03 03:56:39
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-02-03 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 194 tests, 15 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Steve B. <Ste...@an...> - 2005-02-03 03:33:36
|
Hi Jeremy,
I don't know much about valgrind, but...
> Um, are you sure? I think the only interrupts which usable under Linux
> are int3 and int $0x80. int3 is the breakpoint instruction, and is a
> special case because it has a 1 byte opcode rather than 2 bytes.
In Jikes RVM we generate a number of software traps using the INT instruction.
These are int 40 through to int 43. We use these to catch conditions such as
array bounds violations, throw control to a signal handler which then starts our
(Java) execption handling mechanism. So, yes, we do use these, and we catch
them in a regular signal hanler.
> If you try to run any other interrupt, you just get a GPF, which looks
> like a SIGSEGV to user mode (currently we get this wrong by generating a
> SIGILL, but nothing cares).
OK. Perhaps this is right. Perhaps we just look at the culprit instruction and
use the fact that it was an int rather than a load/store to determine what
condition we're handling. We do nonetheless generate an int instruction....
Perhaps all that needs to be done is for valgrind to implemetn the behavior you
describe above: make it look like a SIGSEGV.
Cheers,
--Steve
==21231== Cachegrind, an I1/D1/L2 cache profiler for x86-linux.
==21231== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote et al.
==21231== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==21231== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==21231== For more details, rerun with: -v
==21231==
disInstr: unhandled instruction bytes: 0xCC 0xDF 0x32 0x57
at 0x5732DF9C: ???
Just to give some context, here's a couple of snippits from our baseline
compiler source code:
protected final void emit_ldiv() {
// (1) zero check
asm.emitMOV_Reg_RegDisp(T0, SP, 0);
asm.emitOR_Reg_RegDisp(T0, SP, 4);
VM_ForwardReference fr1 = asm.forwardJcc(asm.NE);
asm.emitINT_Imm(VM_Runtime.TRAP_DIVIDE_BY_ZERO + RVM_TRAP_BASE); // trap
if divisor is 0
....
public final void emitINT_Imm (int v) {
if (VM.VerifyAssertions) VM._assert(v <= 0xFF);
int miStart = mi;
if (v == 3) { // special case interrupt
setMachineCodes(mi++, (byte) 0xCC);
} else {
setMachineCodes(mi++, (byte) 0xCD);
setMachineCodes(mi++, (byte) v);
}
if (lister != null) lister.I(miStart, "INT", v);
}
|
|
From: Tom H. <to...@co...> - 2005-02-03 03:23:58
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-03 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-03 03:21:53
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-03 03:15:13 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-03 03:16:39
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-03 03:10:06 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-03 03:09:44
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-02-03 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 14 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-03 03:04:54
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-02-03 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 13 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-02-03 01:28:51
|
On Wed, 2005-02-02 at 16:48 -0600, Nicholas Nethercote wrote:
> Valgrind currently only supports the 'int' instruction when it is "int
> 0x80", which is used for a system call on x86/Linux. Some Java
> implementations use the x86 'int' ("interrupt") instruction when certain
> exceptions are thrown. Steve Blackburn of ANU was having problems with
> using Cachegrind on some Java programs because of this. I made a quick
> attempt at adding support for these instructions, but failed, so I'm
> asking here about it. I tried adding a new kind of basic-block-ending
> Jmp, and then tried adding a new UCode instruction, INT. I made some
> progress but didn't really get anywhere.
Um, are you sure? I think the only interrupts which usable under Linux
are int3 and int $0x80. int3 is the breakpoint instruction, and is a
special case because it has a 1 byte opcode rather than 2 bytes.
If you try to run any other interrupt, you just get a GPF, which looks
like a SIGSEGV to user mode (currently we get this wrong by generating a
SIGILL, but nothing cares).
> Basically, if anyone knows how these interrupts work, and have ideas about
> how to support them, I'd appreciate knowing about it. Thanks.
I don't think we can in any meaningful way, except for int3. If there's
a real need, I would do it with a simple helper call.
If they are using int3, I implemented it the other day. (Attached, but
it is out of date with respect to the baseBlock removal.)
J
|
|
From: KJK::Hyperion <hac...@re...> - 2005-02-03 00:54:20
|
At 23.48 02/02/2005, Nicholas Nethercote wrote:
>So the pertinent question is this: how does control return to the client
>in user-space?
an interrupt almost invariably translates into a signal raised to the
calling thread. Interrupts were designed with that use in mind (or, most
probably, signals and exceptions were designed with interrupts in mind...).
A really small subset (in Linux, only # 0x80) is actually an abuse and is
used in place of call far <segment>:0 ("call gate" - IIRC, in AT&T syntax
it's lcall <segment>, 0), an abuse probably justified by raw performance
figures (I read somewhere Windows 95 used an invalid opcode, because at the
time the invalid opcode trap was the fastest way to get into kernel mode.
Nowadays we have sysenter)
>Another question: how do we know what the kernel does while servicing the
>interrupt?
you make an educated guess. In most cases, though, it only results in a
signal and the question really is which signal number for a given interrupt
|