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
(7) |
2
(5) |
3
(2) |
4
(8) |
5
(10) |
|
6
(3) |
7
(9) |
8
(7) |
9
(8) |
10
(7) |
11
(4) |
12
(11) |
|
13
(5) |
14
(17) |
15
(6) |
16
(15) |
17
|
18
(3) |
19
(1) |
|
20
(6) |
21
(18) |
22
(5) |
23
(9) |
24
(6) |
25
(3) |
26
(1) |
|
27
(1) |
28
|
29
(8) |
30
(5) |
|
|
|
|
From: <sv...@va...> - 2015-09-07 20:00:12
|
Author: sewardj
Date: Mon Sep 7 21:00:05 2015
New Revision: 15640
Log:
Update.
Modified:
trunk/NEWS
trunk/docs/internals/3_10_BUGSTATUS.txt
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Mon Sep 7 21:00:05 2015
@@ -7,18 +7,19 @@
This release supports X86/Linux, AMD64/Linux, ARM32/Linux,
ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux,
-MIPS32/Linux, MIPS64/Linux, TILEGX/Linux, ARM/Android, ARM64/Android,
-MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris,
-X86/MacOSX 10.10 and 10.11 and AMD64/MacOSX 10.10 and 10.11.
+MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android,
+MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, X86/MacOSX
+10.10 and AMD64/MacOSX 10.10. There is also preliminary support for
+X86/MacOSX 10.11, AMD64/MacOSX 10.11 and TILEGX/Linux.
* ================== PLATFORM CHANGES =================
-* Support for the Tilera TileGX architecture has been added.
-
* Support for Solaris/x86 and Solaris/amd64 has been added.
* Preliminary support for Mac OS X 10.11 (El Capitan) has been added.
+* Preliminary support for the Tilera TileGX architecture has been added.
+
* s390x: It is now required for the host to have the "long displacement"
facility. The oldest supported machine model is z990.
@@ -29,9 +30,16 @@
as a whole somewhat faster, so JIT-intensive activities, for example
program startup, are modestly faster, around 5%.
+* There have been changes to the default settings of several command
+ line flags, as detailed below.
+
+* Intel AVX2 support is more complete (64 bit targets only). On AVX2
+ capable hosts, the simulated CPUID will now indicate AVX2 support.
+
* ==================== TOOL CHANGES ====================
* Memcheck:
+
- The default value for --leak-check-heuristics has been changed from
"none" to "all". This helps to reduce the number of possibly
lost blocks, in particular for C++ applications.
@@ -39,8 +47,8 @@
- The default value for --keep-stacktraces has been changed from
"malloc-then-free" to "malloc-and-free". This has a small cost in
memory (one word per malloc-ed block) but allows Memcheck to show the
- 3 stacktraces of a dangling reference: Where the block was allocated,
- where it was freed, and where it is acccessed after free.
+ 3 stacktraces of a dangling reference: where the block was allocated,
+ where it was freed, and where it is acccessed after being freed.
- The default value for --partial-loads-ok has been changed from "no" to
"yes", so as to avoid false positive errors resulting from some kinds
@@ -54,25 +62,26 @@
- The 'block_list' monitor command has been enhanced:
o it can print a range of loss records
o it now accepts an optional argument 'limited <max_blocks>'
- to control the nr of block printed.
- o if a block has been found using an heuristic, then
+ to control the number of blocks printed.
+ o if a block has been found using a heuristic, then
'block_list' now shows the heuristic after the block size.
o the loss records/blocks to print can be limited to the blocks
found via specified heuristics.
- - The C helper functions used to instrument loads on x86-linux and
- arm-linux (both 32-bit only) have been replaced by handwritten
- assembly sequences. This gives speedups in the region of 0% to 7%
- for those targets only.
-
- - New command line option: --expensive-definedness-checks=yes|no which
- is useful to avoid occasional invalid complaints on optimised code.
- Watchout for runtime degradation: 25% have been observed but, as always,
- this is highly application specific. The default setting is "no".
+ - The C helper functions used to instrument loads on
+ x86-{linux,solaris} and arm-linux (both 32-bit only) have been
+ replaced by handwritten assembly sequences. This gives speedups
+ in the region of 0% to 7% for those targets only.
+
+ - A new command line option, --expensive-definedness-checks=yes|no,
+ which is useful to avoid occasional invalid uninitialised-value
+ errors in optimised code. Watch out for runtime degradation, as
+ this can be up to 25%. As always, though, the slowdown is highly
+ application specific. The default setting is "no".
* Massif:
- - New monitor command 'all_snapshots <filename>' that dumps all
+ - A new monitor command 'all_snapshots <filename>' dumps all
snapshots taken so far.
* Helgrind:
@@ -116,27 +125,27 @@
* When a process dies due to a signal, Valgrind now shows the signal
and the stacktrace at default verbosity (i.e. verbosity 1).
-* Address description logic (used by memcheck and helgrind)
- now describes addresses in anonymous segments, file mmap-ed
- segments, shared memory segments and the brk data segment.
-
-* Option --error-markers=<begin>,<end> can be used to mark
- the begin/end of errors in textual output mode, to facilitate
- searching/extracting errors in output files mixing valgrind
- errors with program output.
+* The address description logic used by Memcheck and Helgrind now
+ describes addresses in anonymous segments, file mmap-ed segments,
+ shared memory segments and the brk data segment.
+
+* The new option --error-markers=<begin>,<end> can be used to mark the
+ begin/end of errors in textual output mode, to facilitate
+ searching/extracting errors in output files that mix valgrind errors
+ with program output.
-* New option --max-threads=<number> can be used to change the number
+* The new option --max-threads=<number> can be used to change the number
of threads valgrind can handle. The default is 500 threads which
should be more than enough for most applications.
-* New option --valgrind-stacksize=<number> can be used to change the
+* The new option --valgrind-stacksize=<number> can be used to change the
size of the private thread stacks used by Valgrind. This is useful
for reducing memory use or increasing the stack size if Valgrind
segfaults due to stack overflow.
-* New option --avg-transtab-entry-size=<number> can be used to specify
+* The new option --avg-transtab-entry-size=<number> can be used to specify
the expected instrumented block size, either to reduce memory use or
- to avoid excess retranslations.
+ to avoid excessive retranslation.
* Valgrind can be built with Intel's ICC compiler, version 14.0 or later.
@@ -191,6 +200,7 @@
319274 Fix unhandled syscall: unix:410 (sigsuspend_nocancel) on OS X
324181 mmap does not handle MAP_32BIT (handle it now, rather than fail it)
327745 Fix valgrind 3.9.0 build fails on Mac OS X 10.6.8
+330147 libmpiwrap PMPI_Get_count returns undefined value
333051 mmap of huge pages fails due to incorrect alignment
== 339163
334802 valgrind does not always explain why a given option is bad
@@ -236,6 +246,7 @@
341698 Valgrind's AESKEYGENASSIST gives wrong result in words 0 and 2 [..]
341789 aarch64: shmat fails with valgrind on ARMv8
341997 MIPS64: Cavium OCTEON insns - immediate operand handled incorrectly
+342008 valgrind.h needs type cast [..] for clang/llvm in 64-bit mode
342038 Unhandled syscalls on aarch64 (mbind/get/set_mempolicy)
342063 wrong format specifier for test mcblocklistsearch in gdbserver_tests
342117 Hang when loading PDB file for MSVC compiled Firefox under Wine
@@ -359,6 +370,7 @@
350062 vex x86->IR: 0x66 0xF 0x3A 0xB (ROUNDSD) on OS X
350202 Add limited param to 'monitor block_list'
350290 s390x: Support instructions fixbr(a)
+350359 memcheck/tests/x86/fxsave hangs indefinetely on OS X
350809 Fix none/tests/async-sigs for Solaris
350811 Remove reference to --db-attach which has been removed.
350813 Memcheck/x86: enable handwritten assembly helpers for x86/Solaris too
@@ -372,6 +384,7 @@
351858 ldsoexec support on Solaris
351873 Newer gcc doesn't allow __builtin_tabortdc[i] in ppc32 mode
352130 helgrind reports false races for printfs using mempcpy on FILE* state
+352320 arm64 crash on none/tests/nestedfs
n-i-bz Provide implementations of certain compiler builtins to support
compilers that may not provide those
n-i-bz Old STABS code is still being compiled, but never used. Remove it.
Modified: trunk/docs/internals/3_10_BUGSTATUS.txt
==============================================================================
--- trunk/docs/internals/3_10_BUGSTATUS.txt (original)
+++ trunk/docs/internals/3_10_BUGSTATUS.txt Mon Sep 7 21:00:05 2015
@@ -270,8 +270,6 @@
349804 wine/osx: mmap-FIXED(0x1000, 1073741824) failed in UME (load_segment2)
-350359 memcheck/tests/x86/fxsave hangs indefinetely on OS X
-
351632 UNKNOWN fcntl 97 on OS X 10.11
=== other/Win32 =======================================================
@@ -297,8 +295,6 @@
=== MPI ================================================================
-330147 libmpiwrap PMPI_Get_count (should take; simple fix)
-
=== Documentation ======================================================
340571 x86/Linux should no longer claim "almost complete"
@@ -322,9 +318,6 @@
=== Uncategorised/build=================================================
-342008 valgrind.h needs type cast for _zzq_default to compile with
- clang/llvm in 64-bit mode
-
343553 e500 chip now supports it? and,how about armv5
344019 new tool: trackptr to track pointer usage
|
|
From: <sv...@va...> - 2015-09-07 19:40:27
|
Author: sewardj
Date: Mon Sep 7 20:40:20 2015
New Revision: 15639
Log:
Make sure the result value of count_from_Status is defined.
Fixes #330147. [Unverified!]
Modified:
trunk/mpi/libmpiwrap.c
Modified: trunk/mpi/libmpiwrap.c
==============================================================================
--- trunk/mpi/libmpiwrap.c (original)
+++ trunk/mpi/libmpiwrap.c Mon Sep 7 20:40:20 2015
@@ -417,6 +417,7 @@
int err = PMPI_Get_count(status, datatype, &n);
if (cONFIG_DER) VALGRIND_ENABLE_ERROR_REPORTING;
if (err == MPI_SUCCESS) {
+ VALGRIND_MAKE_MEM_DEFINED(&n, sizeof(n));
*recv_count = n;
return True;
} else {
|
|
From: <sv...@va...> - 2015-09-07 19:22:01
|
Author: florian
Date: Mon Sep 7 20:21:54 2015
New Revision: 15638
Log:
Update due to r13991.
Modified:
trunk/memcheck/tests/xml1.stderr.exp-s390x-mvc
Modified: trunk/memcheck/tests/xml1.stderr.exp-s390x-mvc
==============================================================================
--- trunk/memcheck/tests/xml1.stderr.exp-s390x-mvc (original)
+++ trunk/memcheck/tests/xml1.stderr.exp-s390x-mvc Mon Sep 7 20:21:54 2015
@@ -334,6 +334,7 @@
</frame>
</stack>
<auxwhat>Address 0x........ is on thread 1's stack</auxwhat>
+ <auxwhat>in frame #1, created by frame3 (xml1.c:7)</auxwhat>
</error>
<error>
|
|
From: Matthias S. <zz...@ge...> - 2015-09-07 17:57:45
|
Am 24.08.2015 um 21:39 schrieb Matthias Schwarzott: > 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? > Is there a chance to get this into version 3.11? Regards Matthias |
|
From: Julian S. <js...@ac...> - 2015-09-07 13:44:54
|
Hi, I plan to branch for 3.11.0 in the next 24 hours or so. Please yell ASAP if you believe there to be big breakage on the trunk that should be fixed before that. If the branch seems stable then I propose to let the branch stabilise until Mon 21 Sept and release at that point. J |
|
From: <sv...@va...> - 2015-09-07 13:07:08
|
Author: sewardj
Date: Mon Sep 7 14:06:59 2015
New Revision: 3185
Log:
iselStmt, case Ist_Exit: handle the same assisted transfer cases that
iselNext does. Fixes #352320.
Modified:
trunk/priv/host_arm64_isel.c
Modified: trunk/priv/host_arm64_isel.c
==============================================================================
--- trunk/priv/host_arm64_isel.c (original)
+++ trunk/priv/host_arm64_isel.c Mon Sep 7 14:06:59 2015
@@ -3870,9 +3870,7 @@
= mk_baseblock_64bit_access_amode(stmt->Ist.Exit.offsIP);
/* Case: boring transfer to known address */
- if (stmt->Ist.Exit.jk == Ijk_Boring
- /*ATC || stmt->Ist.Exit.jk == Ijk_Call */
- /*ATC || stmt->Ist.Exit.jk == Ijk_Ret */ ) {
+ if (stmt->Ist.Exit.jk == Ijk_Boring) {
if (env->chainingAllowed) {
/* .. almost always true .. */
/* Skip the event check at the dst if this is a forwards
@@ -3892,6 +3890,26 @@
return;
}
+ /* Case: assisted transfer to arbitrary address */
+ switch (stmt->Ist.Exit.jk) {
+ /* Keep this list in sync with that for iselNext below */
+ case Ijk_ClientReq:
+ case Ijk_NoDecode:
+ case Ijk_NoRedir:
+ case Ijk_Sys_syscall:
+ case Ijk_InvalICache:
+ case Ijk_FlushDCache:
+ case Ijk_SigTRAP:
+ case Ijk_Yield: {
+ HReg r = iselIntExpr_R(env, IRExpr_Const(stmt->Ist.Exit.dst));
+ addInstr(env, ARM64Instr_XAssisted(r, amPC, cc,
+ stmt->Ist.Exit.jk));
+ return;
+ }
+ default:
+ break;
+ }
+
/* Do we ever expect to see any other kind? */
goto stmt_fail;
}
|
|
From: <sv...@va...> - 2015-09-07 10:24:05
|
Author: weidendo
Date: Mon Sep 7 11:23:58 2015
New Revision: 15637
Log:
Rephrase Callgrind manual about limiting event aggregation
Modified:
trunk/callgrind/docs/cl-manual.xml
Modified: trunk/callgrind/docs/cl-manual.xml
==============================================================================
--- trunk/callgrind/docs/cl-manual.xml (original)
+++ trunk/callgrind/docs/cl-manual.xml Mon Sep 7 11:23:58 2015
@@ -310,49 +310,78 @@
xreflabel="Limiting range of event collection">
<title>Limiting the range of collected events</title>
- <para>For aggregating events (function enter/leave,
- instruction execution, memory access) into event numbers,
- first, the events must be recognizable by Callgrind, and second,
- the collection state must be enabled.</para>
-
- <para>Event collection is only possible if <emphasis>instrumentation</emphasis>
- for program code is enabled. This is the default, but for faster
- execution (identical to <computeroutput>valgrind --tool=none</computeroutput>),
- it can be disabled until the program reaches a state in which
- you want to start collecting profiling data.
- Callgrind can start without instrumentation
- by specifying option <option><xref linkend="opt.instr-atstart"/>=no</option>.
- Instrumentation can be enabled interactively
- with: <screen>callgrind_control -i on</screen>
- and off by specifying "off" instead of "on".
- Furthermore, instrumentation state can be programatically changed with
- the macros <computeroutput><xref linkend="cr.start-instr"/>;</computeroutput>
- and <computeroutput><xref linkend="cr.stop-instr"/>;</computeroutput>.
+ <para>By default, whenever events are happening (such as an
+ instruction execution or cache hit/miss), Callgrind is aggregating
+ them into event counters. However, you may be interested only in
+ what is happening within a given function or starting from a given
+ program phase. To this end, you can disable event aggregation for
+ uninteresting program parts. While attribution of events to
+ functions as well as producing seperate output per program phase
+ can be done by other means (see previous section), there are two
+ benefits by disabling aggregation. First, this is very
+ fine-granular (e.g. just for a loop within a function). Second,
+ disabling event aggregation for complete program phases allows to
+ switch off time-consuming cache simulation and allows Callgrind to
+ progress at much higher speed with an slowdown of around factor 2
+ (identical to <computeroutput>valgrind
+ --tool=none</computeroutput>).
+ </para>
+
+ <para>There are two aspects which influence whether Callgrind is
+ aggregating events at some point in time of program execution.
+ First, there is the <emphasis>collection state</emphasis>. If this
+ is off, no aggregation will be done. By changing the collection
+ state, you can control event aggregation at a very fine
+ granularity. However, there is not much difference in regard to
+ execution speed of Callgrind. By default, collection is switched
+ on, but can be disabled by different means (see below). Second,
+ there is the <emphasis>instrumentation mode</emphasis> in which
+ Callgrind is running. This mode either can be on or off. If
+ instrumentation is off, no observation of actions in the program
+ will be done and thus, no actions will be forwarded to the
+ simulator which could trigger events. In the end, no events will
+ be aggregated. The huge benefit is the much higher speed with
+ instrumentation switched off. However, this only should be used
+ with care and in a coarse fashion: every mode change resets the
+ simulator state (ie. whether a memory block is cached or not) and
+ flushes Valgrinds internal cache of instrumented code blocks,
+ resulting in latency penalty at switching time. Also, cache
+ simulator results directly after switching on instrumentation will
+ be skewed due to identified cache misses which would not happen in
+ reality (if you care about this warm-up effect, you should make
+ sure to temporarly have collection state switched off directly
+ after turning instrumentation mode on). However, switching
+ instrumentation state is very useful to skip larger program phases
+ such as an initialization phase. By default, instrumentation is
+ switched on, but as with the collection state, can be changed by
+ various means.
+ </para>
+
+ <para>Callgrind can start with instrumentation mode switched off by
+ specifying
+ option <option><xref linkend="opt.instr-atstart"/>=no</option>.
+ Afterwards, instrumentation can be controlled in two ways: first,
+ interactively with: <screen>callgrind_control -i on</screen> (and
+ switching off again by specifying "off" instead of "on"). Second,
+ instrumentation state can be programatically changed with the
+ macros <computeroutput><xref linkend="cr.start-instr"/>;</computeroutput>
+ and <computeroutput><xref linkend="cr.stop-instr"/>;</computeroutput>.
</para>
-
- <para>In addition to enabling instrumentation, you must also enable
- event collection for the parts of your program you are interested in.
- By default, event collection is enabled everywhere.
- You can limit collection to a specific function
- by using
- <option><xref linkend="opt.toggle-collect"/>=function</option>.
- This will toggle the collection state on entering and leaving
- the specified functions.
- When this option is in effect, the default collection state
- at program start is "off". Only events happening while running
- inside of the given function will be collected. Recursive
- calls of the given function do not trigger any action.</para>
-
- <para>It is important to note that with instrumentation disabled, the
- cache simulator cannot see any memory access events, and thus, any
- simulated cache state will be frozen and wrong without instrumentation.
- Therefore, to get useful cache events (hits/misses) after switching on
- instrumentation, the cache first must warm up,
- probably leading to many <emphasis>cold misses</emphasis>
- which would not have happened in reality. If you do not want to see these,
- start event collection a few million instructions after you have enabled
- instrumentation.</para>
+ <para>Similarly, the collection state at program start can be
+ switched off
+ by <option><xref linkend="opt.instr-atstart"/>=no</option>. During
+ execution, it can be controlled programatically with the
+ macro <computeroutput>CALLGRIND_TOGGLE_COLLECT;</computeroutput>.
+ Further, you can limit event collection to a specific function by
+ using <option><xref linkend="opt.toggle-collect"/>=function</option>.
+ This will toggle the collection state on entering and leaving the
+ specified function. When this option is in effect, the default
+ collection state at program start is "off". Only events happening
+ while running inside of the given function will be
+ collected. Recursive calls of the given function do not trigger
+ any action. This option can be given multiple times to specify
+ different functions of interest.</para>
</sect2>
<sect2 id="cl-manual.busevents" xreflabel="Counting global bus events">
|
|
From: <sv...@va...> - 2015-09-07 08:22:10
|
Author: sewardj
Date: Mon Sep 7 09:22:03 2015
New Revision: 3184
Log:
Further kludge stack alignment issues in x86g_dirtyhelper_FXRSTOR.
Fixes (for some definition of "fix") #350359.
Modified:
trunk/priv/guest_x86_helpers.c
Modified: trunk/priv/guest_x86_helpers.c
==============================================================================
--- trunk/priv/guest_x86_helpers.c (original)
+++ trunk/priv/guest_x86_helpers.c Mon Sep 7 09:22:03 2015
@@ -1837,6 +1837,7 @@
/* Code that seems to trigger the problem:
for (i = 0; i < 14; i++) tmp.env[i] = 0; */
for (i = 0; i < 7; i++) tmp.env[i+0] = 0;
+ __asm__ __volatile__("" ::: "memory");
for (i = 0; i < 7; i++) tmp.env[i+7] = 0;
for (i = 0; i < 80; i++) tmp.reg[i] = 0;
|
|
From: <sv...@va...> - 2015-09-07 08:20:53
|
Author: sewardj
Date: Mon Sep 7 09:20:45 2015
New Revision: 15636
Log:
Always use posix_memalign on OS X for consistency. No functional change.
Modified:
trunk/tests/malloc.h
Modified: trunk/tests/malloc.h
==============================================================================
--- trunk/tests/malloc.h (original)
+++ trunk/tests/malloc.h Mon Sep 7 09:20:45 2015
@@ -16,7 +16,7 @@
void* x;
#if defined(VGO_darwin)
// Darwin lacks memalign, but its malloc is always 16-aligned anyway.
- x = malloc(szB);
+ posix_memalign((void **)&x, 16, szB);
#else
x = memalign(16, szB);
#endif
|