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
|
2
(1) |
|
3
|
4
(4) |
5
(4) |
6
|
7
|
8
|
9
|
|
10
(2) |
11
(2) |
12
(2) |
13
|
14
|
15
(2) |
16
(1) |
|
17
(2) |
18
(2) |
19
(3) |
20
(4) |
21
(1) |
22
|
23
|
|
24
(7) |
25
|
26
(4) |
27
(7) |
28
(2) |
29
(1) |
30
(2) |
|
31
|
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2016-07-27 22:10:24
|
On Wed, 2016-07-27 at 14:09 -0400, Christian Convey wrote: > > * With memcheck's "(hw) awatch -l buffer[0]" approach, I cannot tell > > whether the userspace memory-write operation (i.e., column 2) is (a > > read) vs. (a content-changing write) vs. (a content-preserving write). > > Clarification: Since I'm able to use gdb's Python API, I *can* > distinguish (a content-changing write) vs. (a content-preserving > write), if I do my own bookkeeping every time the watchpoint fires. As discussed in the other mail, GDB will not fire a watchpoint if the value did not change. In other words, GDB hides a hw triggered watchpoint when the value did not change. Philippe |
|
From: Philippe W. <phi...@sk...> - 2016-07-27 22:05:37
|
On Wed, 2016-07-27 at 13:40 -0400, Christian Convey wrote: > HI Philippe, > > On Tue, Jul 26, 2016 at 6:00 PM, Philippe Waroquiers > <phi...@sk...> wrote: > > > > On Tue, 2016-07-26 at 16:59 -0400, Christian Convey wrote: > > > Hi Philippe, > > > > IMO this is hard :). > > > Thanks very much for the warning! I will henceforth be less cavalier > > > about that option :) > > At this point, probably worth first experimenting with > > GDB + valgrind gdbserver + memcheck, > > and the watchpoint support by Valgrind gdbserver. > > I took your advice and experimented with: (GDB watches) + (valgrind > gdbserver) + (memcheck). I didn't benchmark timings; I just focused > on what kinds of events the watchpoints detected. > > I created a test program that, in main(), performs the following steps: > 0. Allocate `char buffer[10]` as a local variable, initialized to all 0x00 > characters because of my compiler flags. > > 1. buffer[0] = 'X'; // first write op. Changes the initial value. > > 2. buffer[0] = 'X'; // second write op. Does not change the value. > > 3. buffer[0] = 'Y'; // third write op. Changes the value. > > 4. read( fd, buffer, 10 ); // a syscall that writes a different > // value to buffer[0]. > > 5. After calling `lseek(fd, 0, SEEK_SET);`, repeat the `read` call from > step 4. This is a syscall that writes to buffer[0], but doesn't actually > change its value. > > I then tried various kinds of watchpoint implementations to see which > of the steps above triggered the watchpoint. Here's what I found. > (Apologies for the ASCII art, but I find it helpful.) > > Watchpoint implementation | 1 | 2 | 3 | 4 | 5 | > ==========================+===+===+===+===+===+ > local gdb session | Y | N | Y | Y | Y | > (sw) watch -l buffer[0] | | | | | | The case 5 above is strange. This does not correspond to the GDB documentation: the doc explicitely tells that the expression must change for the watchpoint to trigger. GDB has explicit code to check the value has really changed. So, the case 5 should not have triggered. > --------------------------+---+---+---+---+---+ > local gdb session | Y | N | Y | Y | N | > (hw) watch -l buffer[0] | | | | | | > --------------------------+---+---+---+---+---+ > local gdb session | Y | Y | Y | N | N | > (hw) awatch -l buffer[0] | | | | | | > --------------------------+---+---+---+---+---+ case 2 above is strange, for the same reason as above: there is no read for case 2, and the write did not change the value. Now, maybe GDB cannot differentiate a read from a write that does not change the value for an awatch. But then, case 5 should also have been a Y. And of course, case 4 is equally strange, as 4 changes the value. If the above table is correct, it seems you found several bugs in GDB. > > --------------------------+---+---+---+---+---+ > remote vgdb=full memcheck | Y | N | Y | Y | N | > (sw) watch -l buffer[0] | | | | | | > --------------------------+---+---+---+---+---+ > remote vgdb=full memcheck | Y | N | Y | Y | N | > (hw) watch -l buffer[0] | | | | | | > --------------------------+---+---+---+---+---+ > remote vgdb=full memcheck | Y | Y | Y | Y | N | > (hw) awatch -l buffer[0] | | | | | | > --------------------------+---+---+---+---+---+ > > I included the "local gdb" runs only to satisfy my own curiosity. As > I mentioned earlier, gdb's hardware watchpoints are too restricted for > my needs, and the software watchpoints are too slow. > > Unfortunately it looks like none of the variations I tried is > *exactly* what I want. Perhaps I'm mistaken, but it seems I'm forced > to always make at least one of the following concessions: > > * With memcheck's "(sw/hw) watch -l buffer[0]" approaches, I only > discover that a syscall wrote to the watched memory if it resulted in > a change in that memory's content. (I.e., column "5" is "N") I am quite sure this verification is done by GDB. See in GDB sources breakpoint.c function watchpoint_check. > > * With memcheck's "(hw) awatch -l buffer[0]" approach, I cannot tell > whether the userspace memory-write operation (i.e., column 2) is (a > read) vs. (a content-changing write) vs. (a content-preserving write). > > Do you happen to know if memcheck can be used in a manner which avoids > those problems? The watchpoints in memcheck are implemented using the addressibility bits : a watched location is (artificially) marked as not addressable. So, memcheck detects an error for any read or write, but because the location is watched, memcheck rather reports a hardware watchpoint hit to GDB, rather than producing an error. memcheck clearly knows that the operation is a read or a write. I am wondering if Valgrind gdbserver should not report the precise stop reason: it seems to always report "watch:" stop reason, instead of reporting e.g. rwatch for a read and watch for a write. (see Valgrind code remote-utils.c prepare_resume_reply. In other words, it reports 'watch' and expects that GDB will differentiate the read from the write by checking if the value changed. And then of course, a write that does not change the value is seen as a read. If that is the problem, I think Valgrind gdbserver can be changed so as to report rwatch or watch for respectively a read or a write. > > One possibility does come to mind: I can create multiple memcheck > watchpoints, all covering the same region of memory. I can then > consider which subset of those watchpoints fired for each program > step. Based on that, I can probably get most/all of the information I > want. If you have no better ideas, I may go with this approach rather > than writing my own tool. But this approach is a bit cumbersome in > terms of GDB scripting, so I'm hoping for a more elegant solution. GDB watchpoint concept is based on an expression that changes of value. This works both with sw and hw watchpoints. With GDB, read watchpoints are only working based on hw watchpoints. Not too sure that a write that does not change a value can be differentiated from a read. This is effectively a limitation, not clear how severe this limitation is. > > Thanks again, > Christian |
|
From: Ivo R. <iv...@iv...> - 2016-07-27 19:37:34
|
2016-07-24 14:52 GMT+02:00 Julian Seward <js...@ac...>: > > > 2. Utilize a clean helper function which will compute required output. > > Pros: IR tree will be small, instrumentation relatively fast > > Cons: unclear how to pass effectively inputs and outputs from the helper, > > logic is "hidden" behind the helper > > This is probably your best bet, if you can do it. Can you split the > problem into a sequence of C helper calls, in which each helper takes > 256 or 384 bits of input, and returns a 128 bit result? I used this > technique recently to implement arm64 AES and SHA instructions -- have > a look. > Yes, thank you, I've had a look. But it seems arm64 instructions are not so complex - they take 3 or 4 registers/operands. Sparc crypto instructions are complex - they can take several tens of registers, but no actual operands. > [2] This is better but whether it actually works depends on the exact > details of which registers are accessed, and whether you can describe > that in the dirty-helper side-effect annotations. Which -- I suspect > you will have problems with because of the register windows. Anyway: > * generate a single dirty helper call, passing it a pointer to the > VexGuestSPARC64State struct and any other params you require. > * Write C to do the operations directly on that state > * [the difficult bit] make sure you can actually describe, in the > IRDirty::fxState area, which parts of the register state the > helper reads and writes. If you can't, it's game over :-( > I took this approach with initial 'md5' implementation: https://bitbucket.org/iraisr/valgrind-solaris/commits/dd966b975760920e14342ad5bc076109a3c6942c We do not maintain all register windows in the guest state. After some prototyping, we maintain only the current register window in the guest state, as all normal operations cannot address the other ones, anyway. The other register windows are on the stack, where they would eventually end up anyway. So I think this approach will suit our needs the best. Thank you your response! I. |
|
From: <sv...@va...> - 2016-07-27 18:16:37
|
Author: iraisr
Date: Wed Jul 27 19:16:29 2016
New Revision: 15916
Log:
Add missing x86/Solaris and amd64/Solaris supported platforms.
n-i-bz
Modified:
trunk/README
Modified: trunk/README
==============================================================================
--- trunk/README (original)
+++ trunk/README Wed Jul 27 19:16:29 2016
@@ -42,6 +42,8 @@
- S390X/Linux
- MIPS32/Linux
- MIPS64/Linux
+- X86/Solaris
+- AMD64/Solaris
Note that AMD64 is just another name for x86_64, and Valgrind runs fine
on Intel processors. Also note that the core of MacOSX is called
|
|
From: Christian C. <chr...@gm...> - 2016-07-27 18:10:05
|
> * With memcheck's "(hw) awatch -l buffer[0]" approach, I cannot tell > whether the userspace memory-write operation (i.e., column 2) is (a > read) vs. (a content-changing write) vs. (a content-preserving write). Clarification: Since I'm able to use gdb's Python API, I *can* distinguish (a content-changing write) vs. (a content-preserving write), if I do my own bookkeeping every time the watchpoint fires. - Christian |
|
From: Christian C. <chr...@gm...> - 2016-07-27 17:40:17
|
HI Philippe,
On Tue, Jul 26, 2016 at 6:00 PM, Philippe Waroquiers
<phi...@sk...> wrote:
>
> On Tue, 2016-07-26 at 16:59 -0400, Christian Convey wrote:
> > Hi Philippe,
> > > IMO this is hard :).
> > Thanks very much for the warning! I will henceforth be less cavalier
> > about that option :)
> At this point, probably worth first experimenting with
> GDB + valgrind gdbserver + memcheck,
> and the watchpoint support by Valgrind gdbserver.
I took your advice and experimented with: (GDB watches) + (valgrind
gdbserver) + (memcheck). I didn't benchmark timings; I just focused
on what kinds of events the watchpoints detected.
I created a test program that, in main(), performs the following steps:
0. Allocate `char buffer[10]` as a local variable, initialized to all 0x00
characters because of my compiler flags.
1. buffer[0] = 'X'; // first write op. Changes the initial value.
2. buffer[0] = 'X'; // second write op. Does not change the value.
3. buffer[0] = 'Y'; // third write op. Changes the value.
4. read( fd, buffer, 10 ); // a syscall that writes a different
// value to buffer[0].
5. After calling `lseek(fd, 0, SEEK_SET);`, repeat the `read` call from
step 4. This is a syscall that writes to buffer[0], but doesn't actually
change its value.
I then tried various kinds of watchpoint implementations to see which
of the steps above triggered the watchpoint. Here's what I found.
(Apologies for the ASCII art, but I find it helpful.)
Watchpoint implementation | 1 | 2 | 3 | 4 | 5 |
==========================+===+===+===+===+===+
local gdb session | Y | N | Y | Y | Y |
(sw) watch -l buffer[0] | | | | | |
--------------------------+---+---+---+---+---+
local gdb session | Y | N | Y | Y | N |
(hw) watch -l buffer[0] | | | | | |
--------------------------+---+---+---+---+---+
local gdb session | Y | Y | Y | N | N |
(hw) awatch -l buffer[0] | | | | | |
--------------------------+---+---+---+---+---+
--------------------------+---+---+---+---+---+
remote vgdb=full memcheck | Y | N | Y | Y | N |
(sw) watch -l buffer[0] | | | | | |
--------------------------+---+---+---+---+---+
remote vgdb=full memcheck | Y | N | Y | Y | N |
(hw) watch -l buffer[0] | | | | | |
--------------------------+---+---+---+---+---+
remote vgdb=full memcheck | Y | Y | Y | Y | N |
(hw) awatch -l buffer[0] | | | | | |
--------------------------+---+---+---+---+---+
I included the "local gdb" runs only to satisfy my own curiosity. As
I mentioned earlier, gdb's hardware watchpoints are too restricted for
my needs, and the software watchpoints are too slow.
Unfortunately it looks like none of the variations I tried is
*exactly* what I want. Perhaps I'm mistaken, but it seems I'm forced
to always make at least one of the following concessions:
* With memcheck's "(sw/hw) watch -l buffer[0]" approaches, I only
discover that a syscall wrote to the watched memory if it resulted in
a change in that memory's content. (I.e., column "5" is "N")
* With memcheck's "(hw) awatch -l buffer[0]" approach, I cannot tell
whether the userspace memory-write operation (i.e., column 2) is (a
read) vs. (a content-changing write) vs. (a content-preserving write).
Do you happen to know if memcheck can be used in a manner which avoids
those problems?
One possibility does come to mind: I can create multiple memcheck
watchpoints, all covering the same region of memory. I can then
consider which subset of those watchpoints fired for each program
step. Based on that, I can probably get most/all of the information I
want. If you have no better ideas, I may go with this approach rather
than writing my own tool. But this approach is a bit cumbersome in
terms of GDB scripting, so I'm hoping for a more elegant solution.
Thanks again,
Christian
|
|
From: Will S. <wil...@vn...> - 2016-07-27 14:56:55
|
Hi,
I've been looking at the doCmpORD function, with the intent of fixing
the problem we see on ppc64 where we get a false positive on
"Conditional jump or move depends on uninitialized value(s)".
This currently occurs in the test memcheck/tests/bug340392.c on power,
and variations of this same issue are reported in two bugs, 330617 and
352364.
I admit that I'm still working to understand the code here, and how it
works, hence the questions that follow. :-)
A comment in 352364 ...
>> I'd bet we need a more precise version of CmpORD64S.
> I agree. There is in fact special-case handling already
> for CmpORD{32,64}{S,U} for the case where the second
> argument is a constant zero, but in this case it is a
> constant 0xCD, so it doesn't apply.
And a comment in 330617 ...
> It might be possible to extend the special-casing to
> situations where the 2nd argument is exactly a power
> of 2. That would cover this case.
this makes me wonder if this may be as simple as adding a special case
based on whether yy is actually a constant. This is assuming that if
the value is constant, an assumption can be made that all the bits for
yy are defined.. so would try to use some form of PCast#(0) in place of
yy in that branch of the code.
i.e. " else if (yy->tag == Iex_Const) { ...".
As reference, the code is roughly: (mc_translate.c:doCmpORD() )
if (syned && isZero(yy)) {
/* if yy is zero, then it must be fully defined (zero#). */
threeLeft1 = m64 ? mkU64(3<<1) : mkU32(3<<1);
return binop(opOR,
assignNew( 'V', mce,ty, binop(opAND,
mkPCastTo(mce,ty, xxhash),
threeLeft1)),
assignNew( 'V', mce,ty, binop(opSHL,
assignNew( 'V', mce,ty, binop(opSHR,
xxhash,
mkU8(width-1))),
mkU8(3)))
);
/* standard interpretation */
sevenLeft1 = m64 ? mkU64(7<<1) : mkU32(7<<1);
return binop(
opAND,
mkPCastTo( mce,ty, mkUifU(mce,ty, xxhash,yyhash)),
sevenLeft1);
|