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
(11) |
3
|
4
(9) |
5
(10) |
6
(4) |
7
(14) |
|
8
(15) |
9
(15) |
10
(14) |
11
(13) |
12
(16) |
13
(12) |
14
(9) |
|
15
(21) |
16
(13) |
17
(11) |
18
(13) |
19
(5) |
20
(29) |
21
(20) |
|
22
(13) |
23
(18) |
24
(21) |
25
(17) |
26
(26) |
27
(13) |
28
(17) |
|
29
(10) |
30
(5) |
|
|
|
|
|
|
From: <sv...@va...> - 2014-06-01 17:46:28
|
Author: sewardj
Date: Sun Jun 1 17:46:18 2014
New Revision: 13992
Log:
Update.
Modified:
trunk/docs/internals/3_9_BUGSTATUS.txt
Modified: trunk/docs/internals/3_9_BUGSTATUS.txt
==============================================================================
--- trunk/docs/internals/3_9_BUGSTATUS.txt (original)
+++ trunk/docs/internals/3_9_BUGSTATUS.txt Sun Jun 1 17:46:18 2014
@@ -23,6 +23,15 @@
Probably WONTFIX or CANTFIX
== 328423
+=== VEX/arm64 ==========================================================
+
+335262 arm64: movi 8bit version is not supported
+335263 arm64: dmb instruction is not implemented
+335440 arm64: ld1 (single structure) is not implemented
+335496 arm64: sbc/abc instructions are not implemented
+335554 arm64: unhanded instruction: abs
+335564 arm64: unhandled instruction fcvtpu Xn, Sn
+
=== VEX/x86 ============================================================
333625 Program under valgrind calculates complex exp() wrongly
@@ -177,3 +186,20 @@
333628 Out of tree build (is fixed, but needs to land)
335143 Capabilities not supported
197259 (wine) Unsupported arch_prtctl option
+
+---
+
+334665 vex x86->IR: unhandled instruction bytes: 0xC4 0xE2 0x73 0xF7
+334802 valgrind does not always explain why a given option is bad
+334834 PPC64 Little Endian support, patch 2
+334836 PPC64 Little Endian support, patch 3 testcase fixes
+335034 Unhandled ioctl: HCIGETDEVLIST
+335353 expected output of exp-sgcheck/tests/hackedbz2 mismatch with gcc 4.8.1
+335441 unhandled ioctl 0x8905 (SIOCATMARK) when running wine under valgrind (patch)
+249435 Analyzing wine programs with callgrind triggers a crash (NEEDS CLOSE)
+335563 wine's kernel32/thread test fails under valgrind
+335618 arm(thumb): unhanded instruction: mov.w rN, pc/sp
+335629 Compile error
+
+31 May 2014
+
|
|
From: Julian S. <js...@ac...> - 2014-06-01 17:20:26
|
On 05/23/2014 09:15 AM, Schuele, Tobias wrote: > Hi, we would like to employ Valgrind for dynamic instrumentation of ARM binaries on Linux. > Since the search function at Gmane seems not to work, I wonder if somebody can give > me information about the current status of ARM support. According to the website, it is > "medium" resp. "fairly complete" for 3.7.X. Is there still anything missing in 3.9.0 and > if so, what? Thank you very much in advance! I assume you are referring to 32-bit ARM. If so, there is almost complete instruction set coverage for the ARMv7 instruction set, including SIMD (NEON) and the media-V6 instructions. I routinely run large ARM/Thumb applications on it. J |
|
From: John R.
|
>> The most likely way to implement such a feature in valgrind >> would be to have a Solaris-specific implementation of every system call >> that is affected by the special control word. If <stdlib.h> "read()" >> were affected then there would be a Solaris-specific version of >> "Int VG_(read)" [currently in coregrind/m_libcfile.c] which would >> implement the feature: test the word, call sigprocmask() if necessary, >> etc. That's the more subtle side, the one for valgrind internal uses. The obvious side is the stuff in coregrind/m_syswrap/priv_syswrap-generic.h and so on, which handles tracking the effects of system calls from emulated user code. |
|
From: Ivo R. <iv...@iv...> - 2014-06-01 03:18:39
|
>> I would like to ask what are the possibilities of intercepting a write to a memory address >> under valgrind, regardless of a tool currently used. > > It would be possible, but unlikely. Every store to memory > would have to compare against the address. That's too slow. Thank you for confirming my suspicion. > Instead, perform the comparison only when the result can > possibly affect execution, which is at a system call. That's what I had in my sleeve provided the write interception proves unfeasible. >> ---------------------- >> Motivation is the following: Solaris contains a special >> libc/kernel synchronization mechanism. > > Does this feature of Solaris has a name? Please tell us the name, > and include a link to the documentation. It is called 'schedctl' and you can find the header file here: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/schedctl.h#70 Not much documentation is available, though. The concept is briefly touched here: https://blogs.oracle.com/dave/entry/inverted_schedctl_usage_in_the but it mainly discusses 'sc_preemptctl' flag, not 'sc_sigblock' flag. > Either the address (or an algorithm to compute it) is known in advance > before each thread starts, or the thread performs a system call to > learn the address that the OS has chosen. Please document. The latter - OS provides an address of sc_shared_t (after a corresponding syscall). That piece of memory is then shared between kernel and libc for a particular thread. > One likely possibility is that the address is a fixed offset > into the thread control block, where libc and the kernel > have agreed on the location and layout of that block. Exactly. > The most likely way to implement such a feature in valgrind > would be to have a Solaris-specific implementation of every system call > that is affected by the special control word. If <stdlib.h> "read()" > were affected then there would be a Solaris-specific version of > "Int VG_(read)" [currently in coregrind/m_libcfile.c] which would > implement the feature: test the word, call sigprocmask() if necessary, > etc. It might be necessary to have a Solaris-specific implementation > of EVERY system call where valgrind uses sigprocmask, if valgrind's > current internal use of sigprocmask is not compatible with the semantics > of the Solaris control word. Will investigate. Thank you for responding, I. |
|
From: John R.
|
On 05/31/2014 11:58 AM, Ivo Raisr wrote: > I would like to ask what are the possibilities > of intercepting a write to a memory address > under valgrind, regardless of a tool currently used. It would be possible, but unlikely. Every store to memory would have to compare against the address. That's too slow. Instead, perform the comparison only when the result can possibly affect execution, which is at a system call. > <<snip>> > ---------------------- > Motivation is the following: Solaris contains a special > libc/kernel synchronization mechanism. Does this feature of Solaris has a name? Please tell us the name, and include a link to the documentation. > A piece of per-thread memory is shared between libc and kernel. Either the address (or an algorithm to compute it) is known in advance before each thread starts, or the thread performs a system call to learn the address that the OS has chosen. Please document. One likely possibility is that the address is a fixed offset into the thread control block, where libc and the kernel have agreed on the location and layout of that block. > It is used for various purposes, one is for 'block-all-signals' > flag. Libc prior to certain synchronization operations writes to > that memory indicating to the kernel that all signals should > be blocked. Eventually a regular syscall is invoked; > kernel detects the flag, disables all signals and clears the > flag. The problem here is that setting this flag by libc > bypasses Valgrind's signal machinery which gets confused > by the fact that all signals are disabled in kernel without > knowing it (which would be no problem should this went > through regular syscall sigprocmask & friends). The most likely way to implement such a feature in valgrind would be to have a Solaris-specific implementation of every system call that is affected by the special control word. If <stdlib.h> "read()" were affected then there would be a Solaris-specific version of "Int VG_(read)" [currently in coregrind/m_libcfile.c] which would implement the feature: test the word, call sigprocmask() if necessary, etc. It might be necessary to have a Solaris-specific implementation of EVERY system call where valgrind uses sigprocmask, if valgrind's current internal use of sigprocmask is not compatible with the semantics of the Solaris control word. |