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
(9) |
2
(7) |
3
(15) |
4
(14) |
|
5
(12) |
6
(18) |
7
(16) |
8
(13) |
9
(14) |
10
(20) |
11
(26) |
|
12
(14) |
13
(25) |
14
(20) |
15
(15) |
16
(14) |
17
(13) |
18
(12) |
|
19
(8) |
20
(16) |
21
(15) |
22
(37) |
23
(15) |
24
(18) |
25
(12) |
|
26
(8) |
27
(13) |
28
(12) |
|
|
|
|
|
From: Stephen M.
|
I've recently tried using callgrind and the self-hosting features of recent Valgrind versions in order to profile our Valgrind-based tracing and dynamic analysis tools (http://pag.csail.mit.edu/fjalar/). So far, this seems to work pretty well. However, I ran into one problem with an error coming from the following code in dispatch-x86-linux.S: /* We're leaving. Check that nobody messed with %mxcsr or %fpucw. We can't mess with %eax here as it holds the tentative return value, but any other is OK. */ #if !defined(ENABLE_INNER) /* This check fails for self-hosting, so skip in that case */ pushl $0 fstcw (%esp) cmpl $0x027F, (%esp) popl %esi /* get rid of the word without trashing %eflags */ jnz invariant_violation #endif cmpl $0, VG_(machine_x86_have_mxcsr) jz L2 pushl $0 stmxcsr (%esp) andl $0xFFFFFFC0, (%esp) /* mask out status flags */ cmpl $0x1F80, (%esp) popl %esi jnz invariant_violation L2: /* otherwise we're OK */ jmp run_innerloop_exit_REALLY (the eventual error message is: valgrind: m_scheduler/scheduler.c:994 (vgPlain_scheduler): the 'impossible' happened. valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure ) Since the %fpucw check is commented out, the problems must have been coming from the %mxcsr check, and indeed when I ifdef'ed that out too, things seemed to run fine. I can't say I understand why the %fpucw check fails when you're self-hosting, but it seems at least plausible that a similar issue affects the %mxcsr check. I'm not sure what it is about our tool that tickles this problem; I didn't see similar failures with a memcheck built from a pristine valgrind source (our tool is based in part on memcheck). One potentially significant difference is that we still link with glibc (I get the impression that's discouraged, but we're loathe to give up fprintf() and friends), now statically. The computer I'm seeing this on is an older Athlon that I'm not sure even has an MXCSR register, if that makes a difference. Is ifdeffing out the second check the right fix? -- Stephen |
|
From: Josef W. <Jos...@gm...> - 2006-02-24 22:42:43
|
Hi, it had a short look over the code. On Friday 24 February 2006 13:29, Yao Qi wrote: > The output is simple, just record every instruction and memory access, > but two options in itrace are attractive, --trace-function and > --trace-calltree. The former could enable itrace to filter the output So you print out all instructions where debug info says that they are in this function, right? You decide this in the callback function, which is run for every instruction in the code. Why not decide this already in the instrumentation phase? > and only record instructions in this function you specified, while the > latter could enable itrace to record all instructions in this function > and instructions in functions called by this function. I am not sure if this very simple calltree tracing is the right thing to include into VG source. At least there should be a big warning in the code/docu that this does not work * with multithreaded code (switching to another thread while in the function will leave you with tracing on) * with signal handlers (which will be traced, too) * with functions which are left via a jump (_dl_runtime_resolve, longjmps, perhaps exception handling, handcrafted assembler ...) * only with ISAs where VEX can identify RET instructions (AFAIK for PPC the jumpkind is only a hint here as PPC has no explicit RET instructions) > I include a patch of valgrind-itrace in attachment, and please apply it > to valgrind-3.1.0. I am not the one to decide this, but I think it probably would be nice to add instruction tracing and function filtering (done at instrumentation time) to lackey. Why do you not simply provide an external tool package? You can look at the configure.in and Makefile.am's in callgrind which does exactly this (granted, with some problems regarding biarch support). Josef |
|
From: Yao Qi <qiy...@cn...> - 2006-02-24 12:30:15
|
On Fri, Feb 24, 2006 at 10:26:37AM +0100, Josef Weidendorfer wrote: > > That seems to be already violated: IMHO, lackey is already advanced tutorial stuff > about detecting memory accesses from VEX code. > And summary vs. trace output makes not a huge difference for a valgrind tool > example. The output is simple, just record every instruction and memory access, but two options in itrace are attractive, --trace-function and --trace-calltree. The former could enable itrace to filter the output and only record instructions in this function you specified, while the latter could enable itrace to record all instructions in this function and instructions in functions called by this function. For example, mostly, we are only interested in instructions in one function, they two could filter the output and only display what you want. > I did not see the source if itrace yet, but a problem to integrate it with > lackey would be if you have a lot of corner cases needing some special > handling, which would make it a bad tutorial. itrace/it_main.c is well-commented and less than 500 lines, and the code itself is simple and neat! We start itrace from lackey, and we could integrate itrace with lackey without breaking its simplicity and readability. I include a patch of valgrind-itrace in attachment, and please apply it to valgrind-3.1.0. [qiyao@plinuxt6 valgrind-3.1.0]$ patch -p1 < ../valgrind-3.1.0-itrace-notests.diff patching file configure.in patching file Makefile.am patching file docs/xml/manual.xml patching file itrace/docs/it-manual.xml patching file itrace/docs/Makefile.am patching file itrace/it_main.c patching file itrace/Makefile.am patching file itrace/tests/Makefile.am I did not add test cases into this patch, and I will submit them later when needed! -- Regards, Yao ------------ Yao Qi |
|
From: <sv...@va...> - 2006-02-24 10:36:58
|
Author: njn
Date: 2006-02-24 10:36:54 +0000 (Fri, 24 Feb 2006)
New Revision: 5698
Log:
Minor readability change.
Modified:
trunk/coregrind/m_oset.c
Modified: trunk/coregrind/m_oset.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_oset.c 2006-02-24 09:53:51 UTC (rev 5697)
+++ trunk/coregrind/m_oset.c 2006-02-24 10:36:54 UTC (rev 5698)
@@ -96,7 +96,7 @@
AvlNode* left;
AvlNode* right;
Char balance;
- Char padding[sizeof(void*)-3];
+ Char padding[sizeof(void*)-sizeof(Char)-sizeof(Short)];
Short magic;
};
=20
|
|
From: <sv...@va...> - 2006-02-24 09:53:56
|
Author: sewardj
Date: 2006-02-24 09:53:51 +0000 (Fri, 24 Feb 2006)
New Revision: 5697
Log:
Update.
Modified:
trunk/docs/internals/3_1_BUGSTATUS.txt
Modified: trunk/docs/internals/3_1_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-24 09:53:11 UTC (rev 5=
696)
+++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-24 09:53:51 UTC (rev 5=
697)
@@ -37,7 +37,7 @@
(TODO: VERIFY 31BRANCH)
v5427 v5451 n-i-bz OSet 64-bit fastcmp bug
v5445 v5673 n-i-bz VG_(getgroups) fix (Shinichi Noda)
-vx1519 pending n-i-bz ppc32/64: allocate from callee-saved FP/VMX=
regs
+vx1519 vx1578 n-i-bz ppc32/64: allocate from callee-saved FP/VMX=
regs
v5500 v5674 n-i-bz misaligned path word-size bug in mc_main.c
vx1521/2 pending 119297 Incorrect error message for sse code
pending pending 120410 x86: prefetchw (0xF 0xD 0x48 0x4)
@@ -57,11 +57,10 @@
v5651 v5679 121901 no support for syscall tkill
=20
(next 3 are ppc32-specific FP problems)
-many pending n-i-bz ppc32 rounding mode problems
+many v5694/5 n-i-bz ppc32 rounding mode problems
Is fixed properly in head
For 31BRANCH copy in r5591 kludge
-many wontfix 119482 ppc32: mtfsb1
- [skip for 3.1.1 unless gcc/glibc requires i=
t]
+many vx1577 119482 ppc32: mtfsb1
many wontfix 120277 ppc32: fres, fctid, fctidz, frsqrte=20
[skip for 3.1.1 unless gcc/glibc requires i=
t]
=20
|
|
From: <sv...@va...> - 2006-02-24 09:53:21
|
Author: njn
Date: 2006-02-24 09:53:11 +0000 (Fri, 24 Feb 2006)
New Revision: 5696
Log:
Remove a bogus assertion, and make the shadow memory measurement 64-bit
clean.
Modified:
branches/COMPVBITS/coregrind/m_oset.c
branches/COMPVBITS/memcheck/mc_main.c
Modified: branches/COMPVBITS/coregrind/m_oset.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/coregrind/m_oset.c 2006-02-23 23:26:57 UTC (rev 56=
95)
+++ branches/COMPVBITS/coregrind/m_oset.c 2006-02-24 09:53:11 UTC (rev 56=
96)
@@ -95,7 +95,7 @@
AvlNode* left;
AvlNode* right;
Char balance;
- Char padding[sizeof(void*)-3];
+ Char padding[sizeof(void*)-sizeof(Char)-sizeof(Short)];
Short magic;
};
=20
Modified: branches/COMPVBITS/memcheck/mc_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/mc_main.c 2006-02-23 23:26:57 UTC (rev 56=
95)
+++ branches/COMPVBITS/memcheck/mc_main.c 2006-02-24 09:53:11 UTC (rev 56=
96)
@@ -315,8 +315,6 @@
=20
static void update_SM_counts(SecMap* oldSM, SecMap* newSM)
{
- tl_assert(oldSM !=3D newSM);
- =20
if (oldSM =3D=3D &sm_distinguished[SM_DIST_NOACCESS]) n_noaccess=
_SMs--;
else if (oldSM =3D=3D &sm_distinguished[SM_DIST_WRITABLE]) n_writable=
_SMs--;
else if (oldSM =3D=3D &sm_distinguished[SM_DIST_READABLE]) n_readable=
_SMs--;
@@ -3988,10 +3986,11 @@
=20
// Three DSMs, plus the non-DSM ones
max_SMs_szB =3D (3 + max_non_DSM_SMs) * sizeof(SecMap);
- // The 12 bytes is the AVL node metadata size.
- // The 16 bytes is the malloc metadata size.
- // Hardwiring the numbers in sucks, but I don't see how else to do=
it.
- max_secVBit_szB =3D max_secVBit_nodes * (sizeof(SecVBitNode) + 12 =
+ 16);
+ // The 3*sizeof(Word) bytes is the AVL node metadata size.
+ // The 4*sizeof(Word) bytes is the malloc metadata size.
+ // Hardwiring these sizes in sucks, but I don't see how else to do=
it.
+ max_secVBit_szB =3D max_secVBit_nodes *=20
+ (sizeof(SecVBitNode) + 3*sizeof(Word) + 4*sizeof(Word));
max_shmem_szB =3D sizeof(primary_map) + max_SMs_szB + max_secVBi=
t_szB;
=20
VG_(message)(Vg_DebugMsg,
|
|
From: <js...@ac...> - 2006-02-24 09:40:11
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-24 02:00:01 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Josef W. <Jos...@gm...> - 2006-02-24 09:26:47
|
On Friday 24 February 2006 10:04, Geoff Smith wrote: > If lackey actually does -trace-mem, simply adding -trace-instr seems like > a natural. We actually used lackey as the model for the itrace tool. > > I can think of a couple reasons not to monkey with lackey: a.) lackey's > ouput is completely oriented toward generating a summary (at least if you > only consider documented options <g>); That seems to be already violated: IMHO, lackey is already advanced tutorial stuff about detecting memory accesses from VEX code. And summary vs. trace output makes not a huge difference for a valgrind tool example. I did not see the source if itrace yet, but a problem to integrate it with lackey would be if you have a lot of corner cases needing some special handling, which would make it a bad tutorial. > b.) don't want to gum up the > "model" tool Perhaps it would be a better idea to additionally have a really easy tool as tutorial; but perhaps this already is provided with the "none" tool? Another "model" I like to see is for how to make an external tool, which can be distributed separatly from VG source, with its own configure, using installed VG include files and linking to installed VG libs. > The only serious qualm I might have with --trace-instr is that we'd like > to keep the output both terse (small) and easily parsable. Something like --trace-mem is probably always used for postprocessing. So easy parsing should be mandatory. I think that Nick added memory access tracing because this is kind of a FAQ, and people can use lackey as starting point (similar as you did). Josef |
|
From: Geoff S. <gs...@us...> - 2006-02-24 09:03:41
|
> > I would like to send this request to maillist for an open discussion. > > > > Geoff Smith proposed an idea about Instruction Trace at > > http://sourceforge.net/mailarchive/message.php?msg_id=14760370 > > and I would like to explain and advocate his proposal. > > It seems to me that lackey does already a lot of it, especially with > the --trace-mem=yes option in Valgrind SVN (or was this already in > 3.1? "--help" does not talk about it). > > Perhaps it is a better idea to add the missing things to lackey? > AFAICS things missing in lackey wrt itrace: > - print PC together with memory accesses (--trace-instr=yes) > - enable detailed access trace only for some function(s) If lackey actually does -trace-mem, simply adding -trace-instr seems like a natural. We actually used lackey as the model for the itrace tool. I can think of a couple reasons not to monkey with lackey: a.) lackey's ouput is completely oriented toward generating a summary (at least if you only consider documented options <g>); b.) don't want to gum up the "model" tool The only serious qualm I might have with --trace-instr is that we'd like to keep the output both terse (small) and easily parsable. Ideally, you could write an awk script to do simple analysis. (I haven't seen any trace-mem sample output yet, I should get a chance in the morning.) |
|
From: Geoff S. <gs...@us...> - 2006-02-24 09:03:37
|
Julian Seward <js...@ac...> wrote on 02/23/2006 10:07:42 AM: > > > How have you used it? > > > Nick > > > > We took the output trace and fed it into a tool that displays pipeline > > stalls for the Power5 processor. Recently, we have been working on > > improving the performance of a few key routines in glibc. We're currently > > looking at a few functions in the math libraries. > > So the output format of itrace is the same as the input format of your > pipeline tool? (Is the latter open-source?) Not quite, but we wrote a small adapter to convert itrace's straightforward format to the format the pipeline tool wanted. The pipeline tool is not open-source, but it is freely available (as a binary) on IBM's alphaworks site -- it's called IBM Performance Simulator. It's available for a couple processors. For my part, this is just one possible use for itrace, and not even a particularly interesting one (to me, anyway). I am much more interested in code coverage -- this looks like a tractable way to get coverage on optimized code, which is something gcov can't do. Of course, the kinds of projects that need object-level coverage are probably not considering Linux (yet). |
|
From: <js...@ac...> - 2006-02-24 03:58:59
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-24 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2006-02-24 03:57:05
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-02-24 04:40:00 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 197 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) |
|
From: Tom H. <to...@co...> - 2006-02-24 03:43:37
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-24 03:30:03 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-24 03:30:37
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-24 03:15:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 224 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-24 03:24:52
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-24 03:00:03 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-24 03:24:04
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-24 03:10:11 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-24 03:19:59
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-24 03:05:10 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <sv...@va...> - 2006-02-24 00:14:33
|
Author: sewardj
Date: 2006-02-24 00:14:29 +0000 (Fri, 24 Feb 2006)
New Revision: 1578
Log:
Partially merge r1519 (only allocate from callee-save FP and VMX regs).
Modified:
branches/VEX_3_1_BRANCH/priv/host-ppc32/hdefs.c
Modified: branches/VEX_3_1_BRANCH/priv/host-ppc32/hdefs.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VEX_3_1_BRANCH/priv/host-ppc32/hdefs.c 2006-02-23 23:47:56 U=
TC (rev 1577)
+++ branches/VEX_3_1_BRANCH/priv/host-ppc32/hdefs.c 2006-02-24 00:14:29 U=
TC (rev 1578)
@@ -227,14 +227,16 @@
// GPR30 AltiVec spill reg temporary
// GPR31 =3D GuestStatePtr
=20
- (*arr)[i++] =3D hregPPC32_FPR0();
- (*arr)[i++] =3D hregPPC32_FPR1();
- (*arr)[i++] =3D hregPPC32_FPR2();
- (*arr)[i++] =3D hregPPC32_FPR3();
- (*arr)[i++] =3D hregPPC32_FPR4();
- (*arr)[i++] =3D hregPPC32_FPR5();
- (*arr)[i++] =3D hregPPC32_FPR6();
- (*arr)[i++] =3D hregPPC32_FPR7();
+ /* For both ppc32-linux and ppc64-linux, f14-f31 are callee save.
+ So use them. */
+ (*arr)[i++] =3D hregPPC32_FPR14();
+ (*arr)[i++] =3D hregPPC32_FPR15();
+ (*arr)[i++] =3D hregPPC32_FPR16();
+ (*arr)[i++] =3D hregPPC32_FPR17();
+ (*arr)[i++] =3D hregPPC32_FPR18();
+ (*arr)[i++] =3D hregPPC32_FPR19();
+ (*arr)[i++] =3D hregPPC32_FPR20();
+ (*arr)[i++] =3D hregPPC32_FPR21();
/*
(*arr)[i++] =3D hregPPC32_FPR8();
(*arr)[i++] =3D hregPPC32_FPR9();
@@ -261,14 +263,16 @@
(*arr)[i++] =3D hregPPC32_FPR30();
(*arr)[i++] =3D hregPPC32_FPR31();
*/
- (*arr)[i++] =3D hregPPC32_VR0();
- (*arr)[i++] =3D hregPPC32_VR1();
- (*arr)[i++] =3D hregPPC32_VR2();
- (*arr)[i++] =3D hregPPC32_VR3();
- (*arr)[i++] =3D hregPPC32_VR4();
- (*arr)[i++] =3D hregPPC32_VR5();
- (*arr)[i++] =3D hregPPC32_VR6();
- (*arr)[i++] =3D hregPPC32_VR7();
+ /* For both ppc32-linux and ppc64-linux, v20-v31 are callee-save.
+ So use them. */
+ (*arr)[i++] =3D hregPPC32_VR20();
+ (*arr)[i++] =3D hregPPC32_VR21();
+ (*arr)[i++] =3D hregPPC32_VR22();
+ (*arr)[i++] =3D hregPPC32_VR23();
+ (*arr)[i++] =3D hregPPC32_VR24();
+ (*arr)[i++] =3D hregPPC32_VR25();
+ (*arr)[i++] =3D hregPPC32_VR26();
+ (*arr)[i++] =3D hregPPC32_VR27();
/*
(*arr)[i++] =3D hregPPC32_VR8();
(*arr)[i++] =3D hregPPC32_VR9();
|