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: 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.
|