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
(25) |
4
(4) |
5
|
6
(3) |
7
|
|
8
(2) |
9
(3) |
10
|
11
|
12
|
13
(2) |
14
|
|
15
(1) |
16
(3) |
17
(1) |
18
(7) |
19
(4) |
20
(1) |
21
(2) |
|
22
(1) |
23
(3) |
24
(8) |
25
(1) |
26
(6) |
27
(2) |
28
|
|
29
(3) |
30
|
|
|
|
|
|
|
From: John R. <jr...@bi...> - 2015-11-24 23:17:51
|
On 11/24/2015 02:15 PM, Florian Krohm wrote: > OK, thanks for the explanation. Attached is the patch I'm proposing > which removes the ad-hoc limitation and allows shift amounts up to and > including 31. I looked at the downstream code and it has not problems > handling such shift amounts. > I'm copying Julian to he can chime in and offer an explanation as to why > that limitation existed at all. If there is no yelling I'm going to > commit this in the next couple of days. Shift counts up through 30 [== (2 * 15)] are legal and do work. There is a gray area if the effective absolute value (imm << shift) exceeds something like (1<<18) or (1<<20). Extending or truncating the stack by that much deserves a warning. The danger is "switching segments" without being aware of it. -- |
|
From: Florian K. <fl...@ei...> - 2015-11-24 22:15:51
|
OK, thanks for the explanation. Attached is the patch I'm proposing which removes the ad-hoc limitation and allows shift amounts up to and including 31. I looked at the downstream code and it has not problems handling such shift amounts. I'm copying Julian to he can chime in and offer an explanation as to why that limitation existed at all. If there is no yelling I'm going to commit this in the next couple of days. Florian On 24.11.2015 21:14, Michael Daniels wrote: >> are there other values >4 possible, that we should handle as well? > > Shifts are 5 bits, so its possible this value could be as high as 31. > Like the other patch, the check could/should probably just be > removed altogether. It was just not clear why it was limited in the > first place, so I only bumped it as needed. > ________________________________________ > From: Florian Krohm [fl...@ei...] > Sent: Tuesday, November 24, 2015 2:48 PM > To: Michael Daniels; val...@li... > Subject: Re: [Valgrind-developers] [PATCH][VEX] Bump allowed shift value for "add.w reg, sp, reg, lsl #N" > > I'm not familiar with arm. But I'm wondering whether allowing teh value > 4 here is the right thing to do. Or, phrased differently: are there > other values >4 possible, that we should handle as well? > > Florian > > > On 19.11.2015 17:51, Michael Daniels wrote: >> Hello, >> >> When using GCC 5.2 I am seeing this assembly generated in some cases: >> >> add.w reg, sp, reg, lsl #4 >> >> The current limit is 3 though, so it was causing it to be caught as an unhandled instruction. >> >> Patch attached to bump the number from 3 to 4. >> >> Thanks, >> >> Mike >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > > |
|
From: Michael D. <mda...@qn...> - 2015-11-24 20:14:46
|
> are there other values >4 possible, that we should handle as well? Shifts are 5 bits, so its possible this value could be as high as 31. Like the other patch, the check could/should probably just be removed altogether. It was just not clear why it was limited in the first place, so I only bumped it as needed. ________________________________________ From: Florian Krohm [fl...@ei...] Sent: Tuesday, November 24, 2015 2:48 PM To: Michael Daniels; val...@li... Subject: Re: [Valgrind-developers] [PATCH][VEX] Bump allowed shift value for "add.w reg, sp, reg, lsl #N" I'm not familiar with arm. But I'm wondering whether allowing teh value 4 here is the right thing to do. Or, phrased differently: are there other values >4 possible, that we should handle as well? Florian On 19.11.2015 17:51, Michael Daniels wrote: > Hello, > > When using GCC 5.2 I am seeing this assembly generated in some cases: > > add.w reg, sp, reg, lsl #4 > > The current limit is 3 though, so it was causing it to be caught as an unhandled instruction. > > Patch attached to bump the number from 3 to 4. > > Thanks, > > Mike > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Florian K. <fl...@ei...> - 2015-11-24 20:01:28
|
I'm not familiar with arm. But I'm wondering whether allowing teh value 4 here is the right thing to do. Or, phrased differently: are there other values >4 possible, that we should handle as well? Florian On 19.11.2015 17:51, Michael Daniels wrote: > Hello, > > When using GCC 5.2 I am seeing this assembly generated in some cases: > > add.w reg, sp, reg, lsl #4 > > The current limit is 3 though, so it was causing it to be caught as an unhandled instruction. > > Patch attached to bump the number from 3 to 4. > > Thanks, > > Mike > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Florian K. <fl...@ei...> - 2015-11-24 19:39:40
|
Well spotted! Thanks for the report. I applied yor patch as r15737.
Florian
On 19.11.2015 17:35, Michael Daniels wrote:
> Hello,
>
> The inline assembly in do_cmpxchg8b() clobbers rbx, but it is not in the clobber list (likely just a spelling mistake, as rdx is in there twice). This was causing problems for me when running this test on our platform.
>
> Simple patch attached.
>
> Thanks,
>
> Mike
|
|
From: <sv...@va...> - 2015-11-24 19:38:24
|
Author: florian
Date: Tue Nov 24 19:38:16 2015
New Revision: 15737
Log:
Fix a typo in the clobber list.
Spotted by Michael Daniels <mda...@qn...>
Modified:
trunk/none/tests/amd64/xacq_xrel.c
Modified: trunk/none/tests/amd64/xacq_xrel.c
==============================================================================
--- trunk/none/tests/amd64/xacq_xrel.c (original)
+++ trunk/none/tests/amd64/xacq_xrel.c Tue Nov 24 19:38:16 2015
@@ -168,7 +168,7 @@
"movabsq $0xffeeddccbbaa9988, %%rbx" "\n\t"
"xacquire lock cmpxchg8b (%0)" "\n\t"
"xrelease lock cmpxchg8b (%0)" "\n\t"
- : : "r"(&n) : "cc", "memory", "rax", "rdx", "rcx", "rdx"
+ : : "r"(&n) : "cc", "memory", "rax", "rbx", "rcx", "rdx"
);
printf("result for '%-3s' is %016llx\n", "cmpxchg8b", n);
}
|
|
From: Matthias S. <zz...@ge...> - 2015-11-24 19:04:11
|
Am 07.09.2015 um 19:57 schrieb Matthias Schwarzott: > Am 24.08.2015 um 21:39 schrieb Matthias Schwarzott: >> Hi! >> Hi! > I added this latest patch also to this bug: > https://bugs.kde.org/show_bug.cgi?id=191069 > >> Will this patch or at least this idea be considered for commiting? >> Can this patch be considered for applying? It just tries to make the xml output of memcheck be more like the text output. Regards Matthias |
|
From: yoma s. <sop...@gm...> - 2015-11-24 05:16:19
|
hi Azat: 2015-11-23 23:33 GMT+08:00 Azat Khuzhin <a3a...@gm...>: > On Mon, Nov 23, 2015 at 11:18:29PM +0800, yoma sophian wrote: >> 2. there is a option call "--trace-children=yes" to capture all >> children information. >> is it possible to limit the specific child name for tracking? >> if possile, should I use some other valgrind execution options or >> modify the source code? > > From valgrind(1): > ... > --trace-children-skip=patt1,patt2.. > ... > --trace-children-skip-by-arg=patt1,patt2.. > ... BTW, is there any other option that we can focus on some specific child? Thanks for your kind help ^^ |