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
(4) |
2
(7) |
3
(29) |
4
(2) |
|
5
(2) |
6
(14) |
7
(4) |
8
(17) |
9
(19) |
10
(17) |
11
(18) |
|
12
(21) |
13
(22) |
14
(16) |
15
(14) |
16
(2) |
17
|
18
(3) |
|
19
|
20
(1) |
21
(14) |
22
(9) |
23
(13) |
24
|
25
|
|
26
(1) |
27
(12) |
28
(2) |
29
(17) |
30
(14) |
31
(5) |
|
|
From: Rick G. <rcg...@ve...> - 2013-05-02 22:07:02
|
On 5/2/2013 6:18 AM, Julian Seward wrote:
> Greetings.
>
> It'll soon be 9 months since 3.8.0 shipped, so 3.9.0 needs to go out
> in the next two months or so. I'd like to propose a freeze date of
> Friday 31 May (all new features/fixes should be in by then), and a two
> week stabilisation/test period, ending in release, on Friday 14 June.
>
Any chance of the support for AMD's LWP feature making it in?
https://bugs.kde.org/show_bug.cgi?id=317441
With the patch which is attached to that bug, I am able to run code
which utilizes said instructions through valgrind successfully.
Regards,
Rick
|
|
From: <sv...@va...> - 2013-05-02 22:06:47
|
philippe 2013-05-02 23:06:31 +0100 (Thu, 02 May 2013)
New Revision: 13381
Log:
fix gdbsrv inferior calls when PT_GNU_STACK declares stack not executable
With rev 13368, Valgrind obeys PT_GNU_STACK making the stack not
executable. This makes inferior function call with GDB >= 7.5 failing,
as GDB places a breakpoint on the stack, which must be decoded
and translated by Valgrind to have the inferior function call properly done.
=> introduce a special case in the conditions to allow translation
when a segment is not executable but is readable and there is a
breakpoint at the address.
Modified files:
trunk/coregrind/m_gdbserver/m_gdbserver.c
trunk/coregrind/m_translate.c
trunk/coregrind/pub_core_gdbserver.h
Modified: trunk/coregrind/pub_core_gdbserver.h (+3 -0)
===================================================================
--- trunk/coregrind/pub_core_gdbserver.h 2013-04-27 02:34:05 +01:00 (rev 13380)
+++ trunk/coregrind/pub_core_gdbserver.h 2013-05-02 23:06:31 +01:00 (rev 13381)
@@ -76,6 +76,9 @@
Bool VG_(gdbserver_point) (PointKind kind, Bool insert,
Addr addr, int len);
+/* True if there is a breakpoint at addr. */
+Bool VG_(has_gdbserver_breakpoint) (Addr addr);
+
/* Entry point invoked by vgdb when it uses ptrace to cause a gdbserver
invocation. A magic value is passed by vgdb in check as a verification
that the call has been properly pushed by vgdb. */
Modified: trunk/coregrind/m_gdbserver/m_gdbserver.c (+9 -0)
===================================================================
--- trunk/coregrind/m_gdbserver/m_gdbserver.c 2013-04-27 02:34:05 +01:00 (rev 13380)
+++ trunk/coregrind/m_gdbserver/m_gdbserver.c 2013-05-02 23:06:31 +01:00 (rev 13381)
@@ -394,6 +394,15 @@
return True;
}
+Bool VG_(has_gdbserver_breakpoint) (Addr addr)
+{
+ GS_Address *g;
+ if (!gdbserver_called)
+ return False;
+ g = VG_(HT_lookup) (gs_addresses, (UWord)HT_addr(addr));
+ return (g != NULL && g->kind == GS_break);
+}
+
Bool VG_(is_watched)(PointKind kind, Addr addr, Int szB)
{
Word n_elems;
Modified: trunk/coregrind/m_translate.c (+14 -5)
===================================================================
--- trunk/coregrind/m_translate.c 2013-04-27 02:34:05 +01:00 (rev 13380)
+++ trunk/coregrind/m_translate.c 2013-05-02 23:06:31 +01:00 (rev 13381)
@@ -745,9 +745,9 @@
/* --------- Various helper functions for translation --------- */
/* Look for reasons to disallow making translations from the given
- segment. */
+ segment/addr. */
-static Bool translations_allowable_from_seg ( NSegment const* seg )
+static Bool translations_allowable_from_seg ( NSegment const* seg, Addr addr )
{
# if defined(VGA_x86) || defined(VGA_s390x) || defined(VGA_mips32) \
|| defined(VGA_mips64)
@@ -757,7 +757,16 @@
# endif
return seg != NULL
&& (seg->kind == SkAnonC || seg->kind == SkFileC || seg->kind == SkShmC)
- && (seg->hasX || (seg->hasR && allowR));
+ && (seg->hasX
+ || (seg->hasR && (allowR
+ || VG_(has_gdbserver_breakpoint) (addr))));
+ /* If GDB/gdbsrv has inserted a breakpoint at addr, assume this is a valid
+ location to translate if seg is not executable but is readable.
+ This is needed for inferior function calls from GDB: GDB inserts a
+ breakpoint on the stack, and expects to regain control before the
+ breakpoint instruction at the breakpoint address is really
+ executed. For this, the breakpoint instruction must be translated
+ so as to have the call to gdbserver executed. */
}
@@ -852,7 +861,7 @@
allow a chase. */
/* Destination not in a plausible segment? */
- if (!translations_allowable_from_seg(seg))
+ if (!translations_allowable_from_seg(seg, addr))
goto dontchase;
/* Destination is redirected? */
@@ -1418,7 +1427,7 @@
{ /* BEGIN new scope specially for 'seg' */
NSegment const* seg = VG_(am_find_nsegment)(addr);
- if ( (!translations_allowable_from_seg(seg))
+ if ( (!translations_allowable_from_seg(seg, addr))
|| addr == TRANSTAB_BOGUS_GUEST_ADDR ) {
if (VG_(clo_trace_signals))
VG_(message)(Vg_DebugMsg, "translations not allowed here (0x%llx)"
|
|
From: Niall D. <ndo...@bl...> - 2013-05-02 15:05:23
|
> How does that sound? Any counter-proposals? Any other stuff-to-fix? > s390, MIPS and POWER folks, do the proposed dates work for you? I just checked up on the legal state of my patch to callgrind, and absolutely nothing has happened. I'll try to get it to you before end of May, but I'll understand if that's considered too late. The only good thing about the patch is it touches very little of any existing functionality, so code review should be easy with negligible ripples. Niall |
|
From: Thomas R. <tr...@st...> - 2013-05-02 13:24:49
|
Hi, This is somewhat prompted by the "what do we want to go in for 3.9" thread, but I didn't want to hijack it with hypothetical features. I've been working on AMD64 rounding mode support on and off, largely because we need this at $DAYJOB. The ticket https://bugs.kde.org/show_bug.cgi?id=136779 keeps getting stalled. I don't want to sound overly pushy, but it would help me a bit to at least know generally what is holding it up. General disinterest? Disappointment with a 4% slowdown in some cases? Bad design? Broken code? I still want to add a thorough regression test and run it through some stricter testing if I can find something workable tests (probably from the CGAL test suite, if I can get access). But we have been using this in production since before I posted the first version, and that's now more than 2.5 years ago. I have again rebased it and made another big commit to modify the new AVX instruction support to look out for rounding; the relevant commits are currently at https://github.com/trast/valgrind/commits/amd64-rounding for lack of a better place to keep them. I have some other work-in-progress there, notably the regalloc speed improvement hack at https://bugs.kde.org/show_bug.cgi?id=318030 but that is relatively minor. Thanks, -- Thomas Rast trast@{inf,student}.ethz.ch |
|
From: Philippe W. <phi...@sk...> - 2013-05-02 13:18:36
|
On Thu, 2013-05-02 at 11:53 +0200, Julian Seward wrote:
> On 05/01/2013 10:39 PM, Philippe Waroquiers wrote:
> > If no comment on the patch, I will commit in one day or two.
>
> Looks OK, except one comment:
>
> > return seg != NULL
> > && (seg->kind == SkAnonC || seg->kind == SkFileC || seg->kind == SkShmC)
> > - && (seg->hasX || (seg->hasR && allowR));
> > + && (seg->hasX
> > + || (seg->hasR && allowR)
> > + || VG_(has_gdbserver_breakpoint) (addr));
>
> Should the last condition ..
>
> || VG_(has_gdbserver_breakpoint) (addr));
>
> maybe be
>
> || (seg->hasR && VG_(has_gdbserver_breakpoint) (addr)));
>
> ? I am thinking of the case where the segment doesn't even have read
> permissions, but nevertheless VG_(has_gdbserver_breakpoint) returns True.
> In that case, I think VEX will segfault when it starts to make the
> translation, no? We at least need read permissions on any page that we
> make a translation from.
>
> I am not sure about this though -- I can't remember if there is some
> existing logic to deal with the situation where a page is mapped x-only,
> since in that situation vex will need to have r-permission too. So
> maybe this isn't a problem. I don't know.
For the gdbsrv needed condition for the inferior function call
with PT_GNU_STACK not executable stack, the hasR will be True (breakpoint
on the stack which is for sure rw) and the hasX will be False.
=> I will change the condition to:.
&& (seg->hasX
|| (seg->hasR && (allowR
|| VG_(has_gdbserver_breakpoint) (addr))));
Note that the current code accepts to translate an hasX segment
without checking explicitely hasR. Maybe an hasX has automatically hasR ?
It looks better to not change this part of the condition.
Thanks for the review, will retest and commit
Philippe
|
|
From: Julian S. <js...@ac...> - 2013-05-02 10:18:55
|
Greetings.
It'll soon be 9 months since 3.8.0 shipped, so 3.9.0 needs to go out
in the next two months or so. I'd like to propose a freeze date of
Friday 31 May (all new features/fixes should be in by then), and a two
week stabilisation/test period, ending in release, on Friday 14 June.
Considering the stuff still to do (see below), that might be a little
ambitious -- I don't know.
How does that sound? Any counter-proposals? Any other stuff-to-fix?
s390, MIPS and POWER folks, do the proposed dates work for you?
>From a quick look through the NEWS file, new stuff since 3.8.0 is:
- mips64-linux port
- avx2 support
- better control of leak reporting: --show-leak-kinds,
--errors-for-leak-kinds
- better control of block stack traces: --keep-stacktraces
- merge recursive frames in stack unwind: --merge-recursive-frames=
- more GDBserver monitor commands
- greatly improved arm neon load/store performance
- introduction of direct IR support for conditional loads and stores [1]
- use [1] for representing ARM conditional loads/stores [2]
- lots of bugs fixed
- more ppc and zSeries DFP support (?)
If there's stuff I missed there, please add it to the NEWS file.
There's still a number of things I'd like to get fixed before release.
- make avx/avx2 conditional loads/stores use conditional IR loads/stores
- fix memcheck false-errors regression caused by [2]
- fix gdbserver regression caused by loss of executable stack?
- redo various fixed table sizes for android vs big-64-bit-servers
- try to make OSX108 support work better
- memcheck 16-byte reads (PLO) and other icc false-positive workarounds?
- any further Dwarf4 fixes that we need
- remote debuginfo server support [3]
- fix more bugs:
- the usual bunch of missing ioctls, syscalls, etc
- any critical missing insns (I don't think there are many)
- there are a number of bugs for Helgrind which really should
get looked at
- maybe: AMD perfctr support patches
Most of these are documented in docs/internals/3_8_BUGSTATUS.txt.
To clarify re [3]: having spent quite some time Memchecking large apps
on Android, I really would like for the debuginfo reader to be able to
pull debuginfo from a simple (custom) remote server process, since
pushing more than 1GB of debuginfo objects onto the device each time
is a huge time waster. This will involve inserting an abstraction
layer inside m_debuginfo, so it no longer reads debuginfo directly
from the mmap'd objects. This will likely be a big, intrusive change.
J
|
|
From: Julian S. <js...@ac...> - 2013-05-02 09:54:03
|
On 05/01/2013 10:39 PM, Philippe Waroquiers wrote:
> If no comment on the patch, I will commit in one day or two.
Looks OK, except one comment:
> return seg != NULL
> && (seg->kind == SkAnonC || seg->kind == SkFileC || seg->kind == SkShmC)
> - && (seg->hasX || (seg->hasR && allowR));
> + && (seg->hasX
> + || (seg->hasR && allowR)
> + || VG_(has_gdbserver_breakpoint) (addr));
Should the last condition ..
|| VG_(has_gdbserver_breakpoint) (addr));
maybe be
|| (seg->hasR && VG_(has_gdbserver_breakpoint) (addr)));
? I am thinking of the case where the segment doesn't even have read
permissions, but nevertheless VG_(has_gdbserver_breakpoint) returns True.
In that case, I think VEX will segfault when it starts to make the
translation, no? We at least need read permissions on any page that we
make a translation from.
I am not sure about this though -- I can't remember if there is some
existing logic to deal with the situation where a page is mapped x-only,
since in that situation vex will need to have r-permission too. So
maybe this isn't a problem. I don't know.
J
|