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
(23) |
2
(40) |
3
(17) |
4
(10) |
|
5
(14) |
6
(41) |
7
(26) |
8
(23) |
9
(15) |
10
(25) |
11
(14) |
|
12
(23) |
13
(11) |
14
(18) |
15
(21) |
16
(18) |
17
(8) |
18
(14) |
|
19
(16) |
20
(15) |
21
(12) |
22
(11) |
23
(8) |
24
(11) |
25
(12) |
|
26
(9) |
27
(17) |
28
(31) |
29
(16) |
30
(10) |
31
(17) |
|
|
From: Dave N. <dc...@us...> - 2006-03-01 23:43:53
|
I was testing out some of the new instrs in Appendix F of the PowerPC
Instr Set Manual and found that the following instrs cause a Valgrind
Sanity check failure:
rldcl
rldcr
rldic
rldicl
rldicr
rldimi
srdi
Bugzilla report # 122944 identifies the subset of new instrs that aren't
recognized by V 3.1.0. A testcase for those instrs is included in that
report. The above instrs are now recognized by the SVN version (Feb 28)
but get an internal error. Details below.
I ran this on a Power5 running SuSe 9.0, uname -a info:
Linux elm3b149 2.6.5-7.97-pseries64.nm #1 SMP Thu Mar 31 10:55:11 PST
2005 ppc64 ppc64 ppc64 GNU/Linux
==9925== Memcheck, a memory error detector.
==9925== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==9925== Using LibVEX rev 1578, a library for dynamic binary translation.
==9925== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks
LLP.==9925== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation
framework.
==9925== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==9925==
--9925-- Command line
--9925-- a.out
--9925-- Startup, with flags:
--9925-- -v
--9925-- Contents of /proc/version:
--9925-- Linux version 2.6.5-7.97-pseries64.nm (geeko@buildhost) (gcc
version 3.3.3 (SuSE Linux)) #1 SMP Thu Mar 31 10:55:11 PST 2005
--9925-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX
--9925-- Valgrind library directory:
/home/dcn/svn/nightly/valgrind/.in_place
--9925-- Reading syms from /lib/ld-2.3.3.so (0x4100000)
--9925-- Reading syms from /home/dcn/work/bugs/unimpl/a.out (0x10000000)
--9925-- Reading syms from
/home/dcn/svn/nightly/valgrind/memcheck/memcheck-ppc32-linux (0x70000000)
--9925-- object doesn't have a dynamic symbol table
--9925-- Reading suppressions file:
/home/dcn/svn/nightly/valgrind/.in_place/default.supp
--9925-- REDIR: 0x4113040 (strlen) redirected to 0x7002CD00
(vgPlain_ppc32_linux_REDIR_FOR_strlen)
--9925-- REDIR: 0x4112F50 (strcmp) redirected to 0x7002CD28
(vgPlain_ppc32_linux_REDIR_FOR_strcmp)
--9925-- Reading syms from
/home/dcn/svn/nightly/valgrind/coregrind/vgpreload_core-ppc32-linux.so
(0xFFDF000)
--9925-- Reading syms from
/home/dcn/svn/nightly/valgrind/memcheck/vgpreload_memcheck-ppc32-linux.so
(0xFFBA000)
--9925-- Reading syms from /lib/tls/libc.so.6 (0xFE73000)
--9925-- REDIR: 0xFEE7300 (rindex) redirected to 0xFFBD194 (rindex)
IR SANITY CHECK FAILURE
IRBB {
t0:I32 t1:I32 t2:I32 t3:I32 t4:I32 t5:I32 t6:I32 t7:I32
t8:I32 t9:I32 t10:I32 t11:I32 t12:I32 t13:I32 t14:I32
t15:I32
t16:I32 t17:I32 t18:I32 t19:I32 t20:I32 t21:I32 t22:I32
t23:I32
t24:I32 t25:I32 t26:I32 t27:I32 t28:I32 t29:I32 t30:F64
t31:I32
t32:I32 t33:I32 t34:F64 t35:I32 t36:I32 t37:I32 t38:I32
t39:I32
t40:I32 t41:I32 t42:I32 t43:I32 t44:I32 t45:I32 t46:I32
t47:I32
t48:I32 t49:I32 t50:I32 t51:I32 t52:I32 t53:I32 t54:I32
t55:I32
t56:I32 t57:I32 t58:I32 t59:I32 t60:I32 t61:I32 t62:I32
t63:I32
t64:I32 t65:I32 t66:I32 t67:I32 t68:I32 t69:I32 t70:I32
t71:I32
t72:I32 t73:I32 t74:I32 t75:I32 t76:I32 t77:I32 t78:I32
t79:I32
------ IMark(0x10000408, 4) ------
t1 = GET:I32(124)
t0 = GET:I32(4)
t2 = Add32(GET:I32(4),0xFFFFFE10:I32)
PUT(4) = t2
STbe(t2) = t0
------ IMark(0x1000040C, 4) ------
PUT(896) = 0x1000040C:I32
t4 = GET:I32(0)
t3 = GET:I32(124)
t5 = Add32(GET:I32(4),0x1EC:I32)
STbe(t5) = t3
------ IMark(0x10000410, 4) ------
PUT(896) = 0x10000410:I32
t6 = GET:I32(4)
t8 = GET:I32(4)
------ IMark(0x10000414, 4) ------
PUT(896) = 0x10000414:I32
t9 = GET:I32(0) t10 = GET:I32(28)
t11 = 0x3FF00000:I32 PUT(36) = t11
------ IMark(0x10000418, 4) ------ PUT(896) = 0x10000418:I32
t12 = GET:I32(0) t13 = GET:I32(0)
t14 = 0x0:I32 PUT(40) = t14
------ IMark(0x1000041C, 4) ------
PUT(896) = 0x1000041C:I32 t16 = GET:I32(0)
t15 = GET:I32(36)
t17 = Add32(GET:I32(124),0x20:I32)
STbe(t17) = t15
------ IMark(0x10000420, 4) ------
PUT(896) = 0x10000420:I32
t19 = GET:I32(0)
t18 = GET:I32(40)
t20 = Add32(GET:I32(124),0x24:I32)
STbe(t20) = t18
------ IMark(0x10000424, 4) ------
PUT(896) = 0x10000424:I32
t22 = GET:I32(0)
t21 = GET:I32(36)
t23 = Add32(GET:I32(124),0x1D0:I32)
STbe(t23) = t21
------ IMark(0x10000428, 4) ------
PUT(896) = 0x10000428:I32
t25 = GET:I32(0)
t24 = GET:I32(40)
t26 = Add32(GET:I32(124),0x1D4:I32)
STbe(t26) = t24------ IMark(0x1000042C, 4) ------
PUT(896) = 0x1000042C:I32
t28 = GET:I32(124)
t29 = GET:I32(0)
t27 = Add32(GET:I32(124),0x1D0:I32)
PUT(128) = LDbe:F64(t27)
------ IMark(0x10000430, 4) ------
PUT(896) = 0x10000430:I32
t30 = GET:F64(128)
t32 = GET:I32(124)
t33 = GET:I32(0)
t31 = Add32(GET:I32(124),0x18:I32)
STbe(t31) = t30
------ IMark(0x10000434, 4) ------
PUT(896) = 0x10000434:I32
t34 = GET:F64(128)
t36 = GET:I32(124)
t37 = GET:I32(0)
t35 = Add32(GET:I32(124),0x10:I32)
STbe(t35) = t34
------ IMark(0x10000438, 4) ------
PUT(896) = 0x10000438:I32
t38 = GET:I32(124)
t39 = GET:I32(0)
t40 = Add32(t38,0x40:I32)
PUT(0) = t40
------ IMark(0x1000043C, 4) ------
PUT(896) = 0x1000043C:I32
t42 = GET:I32(0)
t41 = GET:I32(0)
t43 = Add32(GET:I32(124),0x2C:I32)
STbe(t43) = t41
------ IMark(0x10000440, 4) ------
PUT(896) = 0x10000440:I32
t44 = GET:I32(0)
t45 = GET:I32(0)
t46 = 0x8:I32------ IMark(0x10000444, 4) ------
PUT(896) = 0x10000444:I32
t48 = GET:I32(0)
t47 = GET:I32(0)
t49 = Add32(GET:I32(124),0x30:I32)
STbe(t49) = t47
------ IMark(0x10000448, 4) ------
PUT(896) = 0x10000448:I32
t50 = GET:I32(0)
t51 = GET:I32(0)
t52 = 0x4:I32
PUT(0) = t52
------ IMark(0x1000044C, 4) ------
PUT(896) = 0x1000044C:I32
t54 = GET:I32(0)
t53 = GET:I32(0)
t55 = Add32(GET:I32(124),0x34:I32)
STbe(t55) = t53
------ IMark(0x10000450, 4) ------
PUT(896) = 0x10000450:I32
t56 = Add32(GET:I32(124),0x2C:I32)
PUT(36) = LDbe:I32(t56)
------ IMark(0x10000454, 4) ------
PUT(896) = 0x10000454:I32
t57 = Add32(GET:I32(124),0x30:I32)
PUT(0) = LDbe:I32(t57)
------ IMark(0x10000458, 4) ------
PUT(896) = 0x10000458:I32
t58 = GET:I32(36)
t60 = GET:I32(0)
t59 =
And64(Mux0X(And8(64to8(t60),0x1F:I8),t58,Or32(Shl32(t58,And8(64to8(t60),0x1F:I8)),Shr32(t58,Sub8(0x20:I8,And8(64to8(t60),0x1F:I8))))),0xFFFFFFFFFFFFFF:I64)
PUT(0) = t59
------ IMark(0x1000045C, 4) ------
PUT(896) = 0x1000045C:I32
t63 = GET:I32(0)
t62 = GET:I32(0)
t64 = Add32(GET:I32(124),0x28:I32)
STbe(t64) = t62
------ IMark(0x10000460, 4) ------
PUT(896) = 0x10000460:I32
t65 = GET:I32(0)
t67 = GET:I32(0)
t66 = t65
PUT(12) = t66
------ IMark(0x10000464, 4) ------
PUT(896) = 0x10000464:I32
t68 = Add32(GET:I32(4),0x0:I32)
PUT(44) = LDbe:I32(t68)
------ IMark(0x10000468, 4) ------
PUT(896) = 0x10000468:I32
t69 = Add32(GET:I32(44),0xFFFFFFFC:I32)
PUT(124) = LDbe:I32(t69)
------ IMark(0x1000046C, 4) ------
PUT(896) = 0x1000046C:I32
t70 = GET:I32(44)
t72 = GET:I32(44)
t71 = t70
PUT(4) = t71
------ IMark(0x10000470, 4) ------
PUT(896) = 0x10000470:I32
t77 = 0xFFFFFFFF:I32
t74 = t77
t78 = 0x1:I32
t75 = t78
t73 = And32(t75,t74)
t76 = And32(GET:I32(900),0xFFFFFFFC:I32)
if (CmpEQ32(t73,0x0:I32)) goto {Boring} 0x10000474:I32
goto {Return} t76
}
IN STATEMENT:
t59 =
And64(Mux0X(And8(64to8(t60),0x1F:I8),t58,Or32(Shl32(t58,And8(64to8(t60),0x1F:I8)),Shr32(t58,Sub8(0x20:I8,And8(64to8(t60),0x1F:I8))))),0xFFFFFFFFFFFFFF:I64)
ERROR = Iex.Unop: arg ty doesn't match op ty
vex: the `impossible' happened:
sanityCheckFail: exiting due to bad IR
vex storage: T total 49760992 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==9925== at 0x7001A614: report_and_quit (m_libcassert.c:136)
==9925== by 0x7001A900: panic (m_libcassert.c:210)
==9925== by 0x7001A940: vgPlain_core_panic_at (m_libcassert.c:215)
==9925== by 0x7001A960: vgPlain_core_panic
(m_libcassert.c:220)==9925== by 0x7002ED88: failure_exit
(m_translate.c:487)
==9925== by 0x7008716C: vpanic (vex_util.c:225)
==9925== by 0x70081DB8: sanityCheckFail (irdefs.c:2023)
==9925== by 0x70082294: tcExpr (irdefs.c:2322)
==9925== by 0x7008229C: tcExpr (irdefs.c:2280)
==9925== by 0x7008212C: tcExpr (irdefs.c:2354)
==9925== by 0x7008229C: tcExpr (irdefs.c:2280)
==9925== by 0x70082F4C: sanityCheckIRBB (irdefs.c:2406)
==9925== by 0x70085D28: LibVEX_Translate (vex_main.c:471)
==9925== by 0x7002F50C: vgPlain_translate (m_translate.c:1097)
==9925== by 0x70044D20: handle_tt_miss (scheduler.c:692)
==9925== by 0x70045458: vgPlain_scheduler (scheduler.c:864)
==9925== by 0x7005B450: thread_wrapper (syswrap-linux.c:86)
==9925== by 0x7005B584: run_a_thread_NORETURN (syswrap-linux.c:119)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==9925== at 0x10000408: main (newinstr.c:2)
PUT(0) = t46
|
|
From: Julian S. <js...@ac...> - 2006-03-01 23:33:20
|
Hi Duncan Modulo my other reply to list on this topic (fix clone, don't fix mmap) I think your understanding is correct: > some questions. This call tells valgrind that all arguments are being > read, right? > > PRE_REG_READ6(long, "mmap2", > unsigned long, start, unsigned long, length, > unsigned long, prot, unsigned long, flags, > unsigned long, fd, unsigned long, offset); I believe so. (peering at priv_types_n_macros.h seems to confirm that). > So presumably I should do PRE_REG_READ4, a PRRAn on the offset > argument, and a PRRAn of the fd argument depending on the value > of flags. That sounds reasonable. Just make sure you do a definedness check on any value you "if" on in the wrapper. But in this case you'd be looking at "flags", which would be tested by a PRE_REG_READ4, so you're ok. > But perhaps there is a better way? Not that I know of. > I notice that > PPRAn is not used anywhere outside of priv_types_n_macros.h, > which suggests that this is the wrong approach. Hmm. Not sure. Ah - one thing. Observe that the PRE_REG_READ macros all start off "if (VG_(tdict).track_pre_reg_read) ...". This stops them using VG_(tdict).track_pre_reg_read in cases where the tool does not care about tracking shadow register values. This means you need to guard all uses of PRRAn with that test, otherwise the system will surely segfault for most tools /= memcheck. Hmm. That's ugly. Maybe there is a better way to conditionally do definedness checks of some scalar syscall args depending on the value of other args. Nick and/or Tom should know, if that is the case. J |
|
From: Julian S. <js...@ac...> - 2006-03-01 23:18:57
|
> However I'd like to make the point that valgrind is presumably concerned
> with portability of the binary, and not of the source code (it doesn't have
> access to the source!). It does not make much sense for valgrind to point
> out a problem with a binary that could only hit on a system where the
> binary is incapable of running. If my binary compiled on a linux system
> can be copied over to a BSD system and run there, then your objection has a
> lot of force. Can it?
Possibly, since some of the BSDs have syscall emulation magic that allows
them to run unmodified binaries.
I guess you could make the PRE(sys_mmap2) fn in syswrap-x86-linux.c
a bit more clever, but I'm inclined to go with John's view, which
is to leave it alone, so as to force programmers to fix their mmap
calls.
clone is a bit different. I say you should fix up the logic in the
wrappers [there's one for each of four supported platforms] to take
notice of the CLONE_CHILD_{SET,CLEAR}TID. The difference is that
clone is linux-specific so there's no harm in making the wrapper
cleverer.
J
|
|
From: John R.
|
> However I'd like to make the point that valgrind is presumably concerned with > portability of the binary, and not of the source code (it doesn't have access > to the source!). It does not make much sense for valgrind to point out a > problem with a binary that could only hit on a system where the binary is > incapable of running. If my binary compiled on a linux system can be copied > over to a BSD system and run there, then your objection has a lot of force. > Can it? (I don't know anything about BSD). Yes it can. Many Linux x86 binary programs "just run" on *BSD x86 and on Sun Solaris x86. Both of these other systems require that the fd parameter to mmap be in range, or -1. -- |
|
From: <sv...@va...> - 2006-03-01 22:36:54
|
Author: sewardj
Date: 2006-03-01 22:36:49 +0000 (Wed, 01 Mar 2006)
New Revision: 5705
Log:
A simple test of m{f,t}ocrf.
Added:
trunk/none/tests/ppc32/mftocrf.c
trunk/none/tests/ppc32/mftocrf.stderr.exp
trunk/none/tests/ppc32/mftocrf.stdout.exp
trunk/none/tests/ppc32/mftocrf.vgtest
Modified:
trunk/none/tests/ppc32/Makefile.am
Modified: trunk/none/tests/ppc32/Makefile.am
=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/none/tests/ppc32/Makefile.am 2006-02-28 13:12:04 UTC (rev 5704)
+++ trunk/none/tests/ppc32/Makefile.am 2006-03-01 22:36:49 UTC (rev 5705)
@@ -6,6 +6,7 @@
jm-int.stderr.exp jm-int.stdout.exp jm-int.vgtest \
jm-fp.stderr.exp jm-fp.stdout.exp jm-fp.vgtest \
jm-vmx.stderr.exp jm-vmx.stdout.exp jm-vmx.vgtest \
+ mftocrf.stderr.exp mftocrf.stdout.exp mftocrf.vgtest \
test_fx.stderr.exp test_fx.stdout.exp test_fx.vgtest \
test_gx.stderr.exp test_gx.stdout.exp test_gx.vgtest \
testVMX.stderr.exp testVMX.stdout.exp testVMX.vgtest \
@@ -13,7 +14,7 @@
xlc_dbl_u32.stderr.exp xlc_dbl_u32.stdout.exp xlc_dbl_u32.vgtest
=20
check_PROGRAMS =3D \
- lsw jm-insns test_fx test_gx testVMX twi xlc_dbl_u32
+ lsw jm-insns mftocrf test_fx test_gx testVMX twi xlc_dbl_u32
=20
AM_CFLAGS =3D $(WERROR) -Winline -Wall -Wshadow -g -I$(top_srcdir)/inc=
lude \
@FLAG_M32@
Added: trunk/none/tests/ppc32/mftocrf.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/none/tests/ppc32/mftocrf.c (rev 0)
+++ trunk/none/tests/ppc32/mftocrf.c 2006-03-01 22:36:49 UTC (rev 5705)
@@ -0,0 +1,66 @@
+
+#include <stdio.h>
+
+static
+int try_mtocrf ( int x )
+{
+ int base =3D 0x31415927;
+ int res;
+
+ /* pre-set CR */
+ __asm__ __volatile__(
+ "mtcr %0"
+ : /*w*/ : /*r*/ "b"(base) : /*trash*/"cc" );
+
+ /* do it */
+ __asm__ __volatile__(
+ "mtocrf 4, %0"
+ : /*w*/ : /*r*/ "b"(x) : /*trash*/"cc" );
+
+ /* get CR */
+ __asm__ __volatile__(
+ "mfcr %0"
+ : /*w*/"=3Db"(res) : /*r*/ );
+
+ return res;
+}
+
+static
+int try_mfocrf ( int x )=20
+{
+ int res;
+ /* CR =3D x */
+ __asm__ __volatile__(
+ "mtcr %0"
+ : /*w*/ : /*r*/ "b"(x) : /*trash*/"cc" );
+
+ /* do it */
+ __asm__ __volatile__(
+ "li %0,0\n\t"
+ "mfocrf %0,64"
+ : /*w*/"=3Db"(res) : /*r*/ );
+
+ return res;
+}
+
+/* This is a bit of a kludge since mfocrf reads the spec'd CR field,
+ but the remaining returned bits are undefined. It seems like on
+ MPC7447A (Apple Mac Mini) mfocrf just reads the entire CR, which is
+ an acceptable implementation, but is not necessarily what other
+ implementations are going to do. */
+
+int main ( void )
+{
+ int i, j;
+ for (i =3D 0; i < 32; i++) {
+ printf("0x%08x\n", try_mtocrf( 1<<i ));
+ }
+ printf("\n");
+ j =3D 1;
+ for (i =3D 0; i < 32; i++) {
+ printf("0x%08x\n", try_mfocrf( j ));
+ j *=3D 3;
+ }
+
+ return 0;
+}
Added: trunk/none/tests/ppc32/mftocrf.stderr.exp
=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/none/tests/ppc32/mftocrf.stderr.exp (re=
v 0)
+++ trunk/none/tests/ppc32/mftocrf.stderr.exp 2006-03-01 22:36:49 UTC (re=
v 5705)
@@ -0,0 +1,2 @@
+
+
Added: trunk/none/tests/ppc32/mftocrf.stdout.exp
=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/none/tests/ppc32/mftocrf.stdout.exp (re=
v 0)
+++ trunk/none/tests/ppc32/mftocrf.stdout.exp 2006-03-01 22:36:49 UTC (re=
v 5705)
@@ -0,0 +1,65 @@
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415127
+0x31415227
+0x31415427
+0x31415827
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+0x31415027
+
+0x00000001
+0x00000003
+0x00000009
+0x0000001b
+0x00000051
+0x000000f3
+0x000002d9
+0x0000088b
+0x000019a1
+0x00004ce3
+0x0000e6a9
+0x0002b3fb
+0x00081bf1
+0x001853d3
+0x0048fb79
+0x00daf26b
+0x0290d741
+0x07b285c3
+0x17179149
+0x4546b3db
+0xcfd41b91
+0x6f7c52b3
+0x4e74f819
+0xeb5ee84b
+0xc21cb8e1
+0x46562aa3
+0xd3027fe9
+0x79077fbb
+0x6b167f31
+0x41437d93
+0xc3ca78b9
+0x4b5f6a2b
Added: trunk/none/tests/ppc32/mftocrf.vgtest
=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/none/tests/ppc32/mftocrf.vgtest (rev 0)
+++ trunk/none/tests/ppc32/mftocrf.vgtest 2006-03-01 22:36:49 UTC (rev 57=
05)
@@ -0,0 +1 @@
+prog: mftocrf
|
|
From: Duncan S. <bal...@fr...> - 2006-03-01 22:17:48
|
Hi John, > > "Syscall param mmap2(fd) contains uninitialised byte(s)" > > It is true that Linux does not examine fd when flags has MAP_ANONYMOUS. > However, *BSD insists that fd must be in the valid range of filedescriptors > for the current process, or be equal to -1, regardless of flags. thanks for the interesting information - now I know why everyone always uses -1! > So memcheck has helped to make the programmer aware of this > portability constraint. But is that the task of valgrind? Clearly valgrind is at least slightly concerned with portability, since it gives warnings for things that may be fine for the computer it is running on (eg: overlapping memcpy, with source higher up in memory than the destination; not a problem on my computer due to the memcpy implementation used, but valgrind still gives a warning), but not fine if the binary is copied to a different system. However I'd like to make the point that valgrind is presumably concerned with portability of the binary, and not of the source code (it doesn't have access to the source!). It does not make much sense for valgrind to point out a problem with a binary that could only hit on a system where the binary is incapable of running. If my binary compiled on a linux system can be copied over to a BSD system and run there, then your objection has a lot of force. Can it? (I don't know anything about BSD). Also, there are more complicated cases. For example, consider "clone" (which is the syscall I'm really interested in). There are two system calls, a two argument one and a five argument one. The five argument one has a parameter child_tidptr which is only accessed if CLONE_CHILD_SETTID or CLONE_CHILD_CLEARTID is set in flags. If you do a normal clone library call without those bits set in flags (note: there is no child_tidptr argument in the library call), then the system library calls the five parameter syscall, using junk in child_tidptr, at least on my system. The author of the program has no control over that - the program is not wrong. The library is not really wrong either. But does this call for a suppression, or for extra logic in valgrind so that it only checks child_tidptr if an appropriate bit is set in flags? All the best, Duncan. |
|
From: Duncan S. <bal...@fr...> - 2006-03-01 21:44:24
|
Hi Tom, > Obviously it is a bit of a bug, but is not trivial to fix and > rarely causes a problem as people normal pass a constant -1 or > something when doing an anonymous map. I agree that it is not very important (and in fact I myself am not much interested in it - I'm interested in a more complicated case with sys_clone; mmap is a warmup). But why do you say it is not trivial to fix? Thanks, Duncan. |
|
From: Duncan S. <bal...@fr...> - 2006-03-01 21:42:31
|
Hi Julian,
> > Is this a valgrind bug, or is there a policy of checking all
> > syscall arguments regardless of whether they will be used or
> > not?
>
> I think it's a bug. Or not exactly a bug: V's syscall wrappers constitute
> an approximate model of how the kernel uses and modifies user-space
> memory across a syscall. What you've found is a place where the model is
> insufficiently accurate. Do you have a patch to improve it?
thanks for replying. I'll be happy to produce a patch, but first I have
some questions. This call tells valgrind that all arguments are being
read, right?
PRE_REG_READ6(long, "mmap2",
unsigned long, start, unsigned long, length,
unsigned long, prot, unsigned long, flags,
unsigned long, fd, unsigned long, offset);
So presumably I should do PRE_REG_READ4, a PRRAn on the offset
argument, and a PRRAn of the fd argument depending on the value
of flags. But perhaps there is a better way? I notice that
PPRAn is not used anywhere outside of priv_types_n_macros.h,
which suggests that this is the wrong approach.
All the best,
Duncan.
|
|
From: <sv...@va...> - 2006-03-01 18:58:46
|
Author: sewardj
Date: 2006-03-01 18:58:39 +0000 (Wed, 01 Mar 2006)
New Revision: 1579
Log:
Implement mtocrf/mfocrf.
Modified:
trunk/priv/guest-ppc/toIR.c
Modified: trunk/priv/guest-ppc/toIR.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/priv/guest-ppc/toIR.c 2006-02-24 00:14:29 UTC (rev 1578)
+++ trunk/priv/guest-ppc/toIR.c 2006-03-01 18:58:39 UTC (rev 1579)
@@ -5232,16 +5232,26 @@
break;
}
=20
- case 0x013: // mfcr (Move from Cond Register, PPC32 p467)
- if (b11to20 !=3D 0) {
- vex_printf("dis_proc_ctl(ppc)(mfcr,b11to20)\n");
- return False;
+ case 0x013:=20
+ // b11to20=3D=3D0: mfcr (Move from Cond Register, PPC32 p467)
+ // b20=3D=3D1 & b11=3D=3D0: mfocrf (Move from One CR Field)
+ // However it seems that the 'mfcr' behaviour is an acceptable
+ // implementation of mfocr (from the 2.02 arch spec)
+ if (b11to20 =3D=3D 0) {
+ DIP("mfcr r%u\n", rD_addr);
+ putIReg( rD_addr, mkSzWiden32(ty, getGST( PPC_GST_CR ),
+ /* Signed */False) );
+ break;
}
- DIP("mfcr r%u\n", rD_addr);
- putIReg( rD_addr, mkSzWiden32(ty, getGST( PPC_GST_CR ),
- /* Signed */False) );
- break;
- =20
+ if (b20 =3D=3D 1 && b11 =3D=3D 0) {
+ DIP("mfocrf r%u,%u\n", rD_addr, CRM);
+ putIReg( rD_addr, mkSzWiden32(ty, getGST( PPC_GST_CR ),
+ /* Signed */False) );
+ break;
+ }
+ /* not decodable */
+ return False;
+ =20
/* XFX-Form */
case 0x153: // mfspr (Move from Special-Purpose Register, PPC32 p470)
=20
@@ -5301,14 +5311,27 @@
break;
}
=20
- case 0x090: { // mtcrf (Move to Cond Register Fields, PPC32 p477)
+ case 0x090: {=20
+ // b20=3D=3D0: mtcrf (Move to Cond Register Fields, PPC32 p477)
+ // b20=3D=3D1: mtocrf (Move to One Cond Reg Field)
Int cr;
UChar shft;
- if (b11 !=3D 0 || b20 !=3D 0) {
- vex_printf("dis_proc_ctl(ppc)(mtcrf,b11|b20)\n");
+ if (b11 !=3D 0)
return False;
+ if (b20 =3D=3D 1) {
+ /* ppc64 v2.02 spec says mtocrf gives undefined outcome if >
+ 1 field is written. It seems more robust to decline to
+ decode the insn if so. */
+ switch (CRM) {
+ case 0x01: case 0x02: case 0x04: case 0x08:
+ case 0x10: case 0x20: case 0x40: case 0x80:
+ break;
+ default:=20
+ return False;=20
+ }
}
- DIP("mtcrf 0x%x,r%u\n", CRM, rS_addr);
+ DIP("%s 0x%x,r%u\n", b20=3D=3D1 ? "mtocrf" : "mtcrf",=20
+ CRM, rS_addr);
/* Write to each field specified by CRM */
for (cr =3D 0; cr < 8; cr++) {
if ((CRM & (1 << (7-cr))) =3D=3D 0)
|
|
From: John R.
|
> Consider a system call like mmap. The fd > parameter is not accessed if MAP_ANONYMOUS > is set in flags, so it doesn't matter if it > contains junk. However valgrind complains > that > "Syscall param mmap2(fd) contains uninitialised byte(s)" It is true that Linux does not examine fd when flags has MAP_ANONYMOUS. However, *BSD insists that fd must be in the valid range of filedescriptors for the current process, or be equal to -1, regardless of flags. So memcheck has helped to make the programmer aware of this portability constraint. -- |
|
From: John R.
|
> Consider a system call like mmap. The fd > parameter is not accessed if MAP_ANONYMOUS > is set in flags, so it doesn't matter if it > contains junk. However valgrind complains > that > "Syscall param mmap2(fd) contains uninitialised byte(s)" I'd say that Valgrind has done you a favor. The message is _exactly_ correct: the program passed uninitialized bytes into the operating system kernel. It happens that today under proper operation these bytes are "don't care": the kernel ignores them. However, from the viewpoint of information security, the program has "leaked" information to a place where there is no need for it to go. Those uninitialized bytes do have a value that was picked up from some discarded state in the program. Perhaps the value is one that would better be kept "secret." Threats posed by malware of various kinds also suggest that it is a good idea not to pass around "uninitialized" bytes. If there should be a program bug somewhere, then uninitialized bytes have a knack for acting as catalyst to amplify the damage and/or spread the confusion and diffuse the recognizable error states. Someday, knowingly processing uninitialized bytes may become a legal liability. [Yeah, that last part is FUD. But the probability of it happening is not zero.] -- |
|
From: Tom H. <to...@co...> - 2006-03-01 12:24:24
|
In message <200...@fr...>
Duncan Sands <bal...@fr...> wrote:
> Consider a system call like mmap. The fd
> parameter is not accessed if MAP_ANONYMOUS
> is set in flags, so it doesn't matter if it
> contains junk. However valgrind complains
> that
> "Syscall param mmap2(fd) contains uninitialised byte(s)"
> This seems to be due to the following
>
> PRE_REG_READ6(long, "mmap2",
> unsigned long, start, unsigned long, length,
> unsigned long, prot, unsigned long, flags,
> unsigned long, fd, unsigned long, offset);
>
> at line 1303 of syswrap-x86-linux.c, which appears to check
> that none of the arguments contains junk.
>
> Is this a valgrind bug, or is there a policy of checking all
> syscall arguments regardless of whether they will be used or
> not?
Obviously it is a bit of a bug, but is not trivial to fix and
rarely causes a problem as people normal pass a constant -1 or
something when doing an anonymous map.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-03-01 12:18:34
|
> Is this a valgrind bug, or is there a policy of checking all > syscall arguments regardless of whether they will be used or > not? I think it's a bug. Or not exactly a bug: V's syscall wrappers constitute an approximate model of how the kernel uses and modifies user-space memory across a syscall. What you've found is a place where the model is insufficiently accurate. Do you have a patch to improve it? J |
|
From: Duncan S. <bal...@fr...> - 2006-03-01 11:36:42
|
Consider a system call like mmap. The fd
parameter is not accessed if MAP_ANONYMOUS
is set in flags, so it doesn't matter if it
contains junk. However valgrind complains
that
"Syscall param mmap2(fd) contains uninitialised byte(s)"
This seems to be due to the following
PRE_REG_READ6(long, "mmap2",
unsigned long, start, unsigned long, length,
unsigned long, prot, unsigned long, flags,
unsigned long, fd, unsigned long, offset);
at line 1303 of syswrap-x86-linux.c, which appears to check
that none of the arguments contains junk.
Is this a valgrind bug, or is there a policy of checking all
syscall arguments regardless of whether they will be used or
not?
Thanks for clarifying.
All the best,
Duncan.
|
|
From: <js...@ac...> - 2006-03-01 10:01:08
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-03-01 02:00:02 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: <js...@ac...> - 2006-03-01 04:08:32
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-03-01 03:30:02 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-03-01 03:54:55
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-03-01 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-03-01 03:44:06
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-03-01 03:30: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 == 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-03-01 03:32:25
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-03-01 03:15:02 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-03-01 03:31:54
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-03-01 03:00:04 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-03-01 03:25:51
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-03-01 03:10:08 GMT Results differ 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, 5 stderr failures, 2 stdout failures ================= memcheck/tests/leakotron (stdout) 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) ================================================= == Results 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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Mar 1 03:18:39 2006 --- new.short Wed Mar 1 03:25:40 2006 *************** *** 8,11 **** ! == 245 tests, 6 stderr failures, 1 stdout failure ================= ! memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) --- 8,11 ---- ! == 245 tests, 5 stderr failures, 2 stdout failures ================= ! memcheck/tests/leakotron (stdout) memcheck/tests/x86/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-01 03:22:30
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-03-01 03:05:13 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: Geoff S. <gs...@us...> - 2006-03-01 00:14:32
|
> > This change (add tracing) continues to move Lackey away from its
> > original purpose - a very simple example tool - and instead changes
> > it into a fairly simple tool which does basic instruction set stuff
> > - insn counts, memory access counts, IR operation counts,
> > trace generation. That's ok by me.
>
> It's ok by me too, because it should be possible to keep the parts
> relatively separate, but having command lines like --do-tracing, and so
you
> can use it as a multi-part tutorial where the parts are effectively
> delineated by "if (clo_do_tracing) { ... }" conditions.
OK, in the absence of other comments, we will proceed along this path.
We'll make a couple of wording changes as well, as suggested by the
discussion on this.
|