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
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
From: Gert W. <gw....@gm...> - 2010-01-21 22:20:15
|
lzcntw r16.uw[0x0468] r16.uw[0] => 1.uw[5] lzcntw m16.uw[0x2642] r16.uw[0] => 1.uw[2] lzcntw r16.uw[0x0000] r16.uw[0] => 1.uw[16] lzcntw r16.uw[0x8000] r16.uw[0] => 1.uw[0] lzcntl r32.ud[0x00072468] r32.ud[0] => 1.ud[13] lzcntl m32.ud[0x75318642] r32.ud[0] => 1.ud[1] lzcntl r32.ud[0x00000000] r32.ud[0] => 1.ud[32] lzcntl r32.ud[0x80000000] r32.ud[0] => 1.ud[0] lzcntq r64.uq[0x1357246813572468] r64.uq[0] => 1.uq[3] lzcntq m64.uq[0x8531864275318642] r64.uq[0] => 1.uq[0] lzcntq m64.uq[0x7531864275318642] r64.uq[0] => 1.uq[1] lzcntq r64.uq[0x0000000000000000] r64.uq[0] => 1.uq[64] |
|
From: Filipe C. <fi...@gm...> - 2010-01-21 16:23:48
|
Hi! The source code is fairly easy to understand (and if you have any doubts, there's always the mailing list ;-) ). Start reading in guest_amd64_toIR.c, line 16206: DisResult disInstr_AMD64 ( ... This function disassembles an AMD64 instruction. Mainly it checks some stuff and calls disInstr_AMD64_WRK, which is the function you're interested in. Understand the control flow: Checking, prefixes, instructions, finalizing. I don't know if that is also a valid Intel instruction... But if it's not, you "just" have to follow the control flow and place the appropriate instructions to deal with it. You'll have to look at the IR in order to see if it already has an instruction for that and, if not, how to implement it using what you have. Best of luck, F On 1/21/10 11:08, Gert Wollny wrote: > Hi all, > > I'd like to work on bug https://bugs.kde.org/show_bug.cgi?id=180217 > vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xC0 0x4C > > I've had a look at the valgrind 3.5.0 code base, and I got some idea > where I would have to fix this in guest_amd64_toIR.c > As far as I can tell, this hasn't been addressed yet in the svn, right? > > However, I guess I could create the needed test cases and edit the part > where the instruction is identified, but from there on I have currently > no idea, how to implement > the required dis_LZCNT_bla function. > Is there some kind of documentation I can read to understand how things > are done or could you suggest a function that I could use as a blueprint? > > Many thanks, > > Gert > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Ashley P. <as...@pi...> - 2010-01-21 15:48:25
|
On 21 Jan 2010, at 02:25, Nicholas Nethercote wrote: > On Thu, Jan 7, 2010 at 12:15 AM, Bjoern Doebel > <bjo...@go...> wrote: >> Hello, >> >> I'm trying to compile Valgrind in a separate build directory, so that >> all generated files etc. are placed outside the source dir. > > https://bugs.kde.org/show_bug.cgi?id=155913 is the bug tracking this feature. The patch attached to that bug should still work, most of the changes are to do with getting the test suite to work rather than actually building Valgrind itself. I need to update it and re-sumit it so let me know if you have any problems with it. Ashley, |
|
From: Gert W. <gw....@gm...> - 2010-01-21 11:14:39
|
Hi all, I'd like to work on bug https://bugs.kde.org/show_bug.cgi?id=180217 vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xC0 0x4C I've had a look at the valgrind 3.5.0 code base, and I got some idea where I would have to fix this in guest_amd64_toIR.c As far as I can tell, this hasn't been addressed yet in the svn, right? However, I guess I could create the needed test cases and edit the part where the instruction is identified, but from there on I have currently no idea, how to implement the required dis_LZCNT_bla function. Is there some kind of documentation I can read to understand how things are done or could you suggest a function that I could use as a blueprint? Many thanks, Gert |
|
From: <sv...@va...> - 2010-01-21 10:24:44
|
Author: tom
Date: 2010-01-21 10:24:37 +0000 (Thu, 21 Jan 2010)
New Revision: 11029
Log:
Make generated pkgconfig file reflect the new locations of the
installed libraries. Patch from Jakub Jelinek. Closes #223657.
Modified:
trunk/valgrind.pc.in
Modified: trunk/valgrind.pc.in
===================================================================
--- trunk/valgrind.pc.in 2010-01-21 10:19:46 UTC (rev 11028)
+++ trunk/valgrind.pc.in 2010-01-21 10:24:37 UTC (rev 11029)
@@ -11,6 +11,6 @@
Description: A dynamic binary instrumentation framework
Version: @VERSION@
Requires:
-Libs: -L${libdir}/valgrind/@VGCONF_ARCH_PRI@-@VGCONF_OS@ -lcoregrind -lvex -lgcc
+Libs: -L${libdir}/valgrind -lcoregrind-@VGCONF_ARCH_PRI@-@VGCONF_OS@ -lvex-@VGCONF_ARCH_PRI@-@VGCONF_OS@ -lgcc
Cflags: -I${includedir}
|
|
From: <sv...@va...> - 2010-01-21 10:20:02
|
Author: tom
Date: 2010-01-21 10:19:46 +0000 (Thu, 21 Jan 2010)
New Revision: 11028
Log:
DW_OP_mod should do unsigned arithmetic. Closes #223656.
Modified:
trunk/coregrind/m_debuginfo/d3basics.c
Modified: trunk/coregrind/m_debuginfo/d3basics.c
===================================================================
--- trunk/coregrind/m_debuginfo/d3basics.c 2010-01-17 11:02:23 UTC (rev 11027)
+++ trunk/coregrind/m_debuginfo/d3basics.c 2010-01-21 10:19:46 UTC (rev 11028)
@@ -770,12 +770,12 @@
PUSH(sw1);
break;
case DW_OP_mod:
- POP(sw2);
- if (sw2 == 0)
+ POP(uw2);
+ if (uw2 == 0)
FAIL("evaluate_Dwarf3_Expr: division by zero");
- POP(sw1);
- sw1 %= sw2;
- PUSH(sw1);
+ POP(uw1);
+ uw1 %= uw2;
+ PUSH(uw1);
break;
#define BINARY(name, op, s) \
case DW_OP_##name: \
|
|
From: Ashley P. <as...@pi...> - 2010-01-21 10:06:38
|
On 21 Jan 2010, at 09:47, Philip Stoev wrote: > This is important in automatic test case simplification where the error must > be reported immediately so that the simplification algorithm can move > forward. > > Any pointers on where in Valgrind's code it would be best to add an extra > exit(), figuratively speaking, would be appreciated. At a guess I'd look for the attach_gdb_on_error code and work from there. As it's possible to specify your own gdb command it might be possible to do this without modifying valgrind by writing a script which kills it's parent process and specifying this script as the "gdb command" to valgrind, you'd be on your own with this but it might be easier to maintain than a valgrind patch. Ashley, |
|
From: Philip S. <ph...@st...> - 2010-01-21 09:47:22
|
Hello, I was wondering how I can achieve an immediate abort at the first valgrind error v.s. waiting for the process to complete and then grepping the error log. This is important in automatic test case simplification where the error must be reported immediately so that the simplification algorithm can move forward. Any pointers on where in Valgrind's code it would be best to add an extra exit(), figuratively speaking, would be appreciated. Thank you! Philip Stoev |
|
From: Nicholas N. <n.n...@gm...> - 2010-01-21 02:25:57
|
On Thu, Jan 7, 2010 at 12:15 AM, Bjoern Doebel <bjo...@go...> wrote: > Hello, > > I'm trying to compile Valgrind in a separate build directory, so that > all generated files etc. are placed outside the source dir. https://bugs.kde.org/show_bug.cgi?id=155913 is the bug tracking this feature. Nick |