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
(20) |
2
(20) |
3
(11) |
4
(10) |
5
(11) |
6
(19) |
|
7
(12) |
8
(22) |
9
(22) |
10
(18) |
11
(11) |
12
(21) |
13
(17) |
|
14
(8) |
15
(16) |
16
(16) |
17
(9) |
18
(19) |
19
(12) |
20
(9) |
|
21
(8) |
22
(12) |
23
(17) |
24
(8) |
25
(8) |
26
(7) |
27
(11) |
|
28
(12) |
29
(16) |
30
(16) |
31
(9) |
|
|
|
|
From: <sv...@va...> - 2007-01-09 20:41:43
|
Author: sewardj Date: 2007-01-09 20:41:41 +0000 (Tue, 09 Jan 2007) New Revision: 6498 Log: Merge r6479 (Replace bcmp in ld.so.1.) Modified: branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c Modified: branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.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/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2007-01-09 = 20:40:44 UTC (rev 6497) +++ branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2007-01-09 = 20:41:41 UTC (rev 6498) @@ -434,6 +434,7 @@ =20 MEMCMP(m_libc_so_star, memcmp) MEMCMP(m_libc_so_star, bcmp) +MEMCMP(m_ld_so_1, bcmp) =20 =20 /* Copy SRC to DEST, returning the address of the terminating '\0' in |
|
From: <sv...@va...> - 2007-01-09 20:40:51
|
Author: sewardj
Date: 2007-01-09 20:40:44 +0000 (Tue, 09 Jan 2007)
New Revision: 6497
Log:
Merge r6495 (handle hinted client mmaps more robustly)
Modified:
branches/VALGRIND_3_2_BRANCH/coregrind/m_syswrap/syswrap-generic.c
Modified: branches/VALGRIND_3_2_BRANCH/coregrind/m_syswrap/syswrap-generi=
c.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/VALGRIND_3_2_BRANCH/coregrind/m_syswrap/syswrap-generic.c 20=
07-01-09 17:09:59 UTC (rev 6496)
+++ branches/VALGRIND_3_2_BRANCH/coregrind/m_syswrap/syswrap-generic.c 20=
07-01-09 20:40:44 UTC (rev 6497)
@@ -1887,6 +1887,25 @@
arg4 | VKI_MAP_FIXED,
arg5, arg6);
=20
+ /* A refinement: it may be that the kernel refused aspacem's choice
+ of address. If we were originally asked for a hinted mapping,
+ there is still a last chance: try again at any address.
+ Hence: */
+ if (mreq.rkind =3D=3D MHint && sres.isError) {
+ mreq.start =3D 0;
+ mreq.len =3D arg2;
+ mreq.rkind =3D MAny;
+ advised =3D VG_(am_get_advisory)( &mreq, True/*client*/, &mreq_ok =
);
+ if (!mreq_ok) {
+ /* Our request was bounced, so we'd better fail. */
+ return VG_(mk_SysRes_Error)( VKI_EINVAL );
+ }
+ /* and try again with the kernel */
+ sres =3D VG_(am_do_mmap_NO_NOTIFY)(advised, arg2, arg3,
+ arg4 | VKI_MAP_FIXED,
+ arg5, arg6);
+ }
+
if (!sres.isError) {
/* Notify aspacem and the tool. */
ML_(notify_aspacem_and_tool_of_mmap)(=20
|
|
From: Tom H. <to...@co...> - 2007-01-09 18:15:44
|
In message <45A3D9DE.2050901@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> It seems to me that there still may be some misunderstandings here.
> These misunderstandings did cause me trouble in the past, particularly
> with randomized placement for mmap() turned on by Fedora Core.
>
> A pageframe that is mapped already is never ("re-")allocated by mmap(),
> unless the mmap specifies MAP_FIXED and the interval covers that page.
Agreed.
> The only reliable way to preserve an address range that V's address space
> manager does not want the kernel to use, is to "reserve" it by using
> mmap(addr, length, PROT_NONE, MAP_ANON|MAP_FIXED,,).
We've been there, done that, and got the T-Shirt. It proved not to be
a workable solution.
> Otherwise the kernel
> is free to use any portion of the interval [addr, length + addr) for
> _any_ mmap(), hinted or not, as long as MAP_FIXED is not requested.
> Randomization is allowed to ignore hints, and sometimes does [has].
> On a 32-bit machine this may require the address space manager to
> track all pageframes; but there are at most 1M pageframes [4KB pages],
> so a 128KB bitmap suffices. On a 64-bit machine the manager probably
> must know something about segments anyway.
What we do now is to maintain a shadow map of the address space, and
apply the allocation rules ourselves and translate all mmap calls into
calls with MAP_FIXED set.
So an mmap with no address hint will cause valgrind to pick an address
that it believes to be free and then do a MAP_FIXED call. With a hint
we try and use the hinted address and if not choose another, then do a
call with MAP_FIXED for the chosen address, A real MAP_FIXED call is
done as is.
So all maps wind up being done as fixed mappings.
> If the virtualizer changes the arguments to a system call, then the
> virtualizer should handle internally any resulting error conditions
> that are due to the changes. The strategy above (handing the failure
> of mmap(,,,MAP_FIXED,,) back to ld.so even though ld.so did not ask
> for MAP_FIXED) violates this rule of good programming practice. The code
> might work today on some systems, but probably it will fail mysteriously
> on other systems or in the future.
Exactly, which is the bug Julian has fixed, that if the fixed call
fails then we try and find another address to use instead. That way
we are preserving the normal kernel behaviour when the hint address
is not available.
> > My fix is: in ML_(generic_PRE_sys_mmap), if the kernel refuses what was
> > originally a hinted mapping, try again as a non-hinted mapping. That
> > appears to fix the problem.
>
> I agree that this is likely to work in many cases. However, a kernel which
> actively randomizes placement of mmap still will cause trouble by violating
> the assumed reservations that the address space manager has not communicated
> to the kernel.
No, because we never let the kernel's address space randomiser get a
look in as we do all maps as fixed ones ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John R.
|
Julian Seward wrote:
> V's address space manager has a clear idea of what address ranges it
> doesn't want the client to use, but it doesn't have a clear idea of what
> ranges the kernel might refuse.
It seems to me that there still may be some misunderstandings here.
These misunderstandings did cause me trouble in the past, particularly
with randomized placement for mmap() turned on by Fedora Core.
A pageframe that is mapped already is never ("re-")allocated by mmap(),
unless the mmap specifies MAP_FIXED and the interval covers that page.
The only reliable way to preserve an address range that V's address space
manager does not want the kernel to use, is to "reserve" it by using
mmap(addr, length, PROT_NONE, MAP_ANON|MAP_FIXED,,). Otherwise the kernel
is free to use any portion of the interval [addr, length + addr) for
_any_ mmap(), hinted or not, as long as MAP_FIXED is not requested.
Randomization is allowed to ignore hints, and sometimes does [has].
On a 32-bit machine this may require the address space manager to
track all pageframes; but there are at most 1M pageframes [4KB pages],
so a 128KB bitmap suffices. On a 64-bit machine the manager probably
must know something about segments anyway.
> ld.so asks for a hinted mapping at 0xFFFDE000, aspacemgr says "ok by me",
> ML_(generic_PRE_sys_mmap) duly presents that to the kernel, but now as
> MAP_FIXED, and the kernel refuses. So the syscall wrapper for mmap hands
> the failure back to ld.so.
If the virtualizer changes the arguments to a system call, then the
virtualizer should handle internally any resulting error conditions
that are due to the changes. The strategy above (handing the failure
of mmap(,,,MAP_FIXED,,) back to ld.so even though ld.so did not ask
for MAP_FIXED) violates this rule of good programming practice. The code
might work today on some systems, but probably it will fail mysteriously
on other systems or in the future.
> My fix is: in ML_(generic_PRE_sys_mmap), if the kernel refuses what was
> originally a hinted mapping, try again as a non-hinted mapping. That
> appears to fix the problem.
I agree that this is likely to work in many cases. However, a kernel which
actively randomizes placement of mmap still will cause trouble by violating
the assumed reservations that the address space manager has not communicated
to the kernel.
--
|
|
From: <sv...@va...> - 2007-01-09 17:10:12
|
Author: sewardj
Date: 2007-01-09 17:09:59 +0000 (Tue, 09 Jan 2007)
New Revision: 6496
Log:
Update
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_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_2_BUGSTATUS.txt 2007-01-09 16:47:20 UTC (rev 6=
495)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2007-01-09 17:09:59 UTC (rev 6=
496)
@@ -32,7 +32,7 @@
pending wontfix 133154 crash when using client requests to=20
register/deregister stack
=20
-pending r6480 32,w 132998 startup fails in when running on UML
+r6481 r6480 32 132998 startup fails in when running on UML
(/proc/self/map start=3D=3Dend problem)
=20
pending pending 32 133327 support for voicetronix ioctl (w/patch)
@@ -171,8 +171,25 @@
Last update was 25 Dec 06
=20
r6462/3 r6464/5 32 n-i-bz glibc-2.5 support
-r6469
=20
+r6469 r6470 32 n-i-bz memcheck: provide replacement for mempcpy
+
+r6479 pending 32 n-i-bz memcheck: replace bcmp in ld.so
+
+vx1716/r6475
+ vx1717/r6476
+ 32 n-i-bz Use 'ifndef' in VEX's Makefile correctly
+
+r6473 r6474 32 n-i-bz Supps for MVL 4.0.1 on ppc32-linux
+
+r6477 r6478 32 n-i-bz libmpiwrap.c: Fixes for MPICH
+
+r6495 pending 32 n-i-bz More robust handling of hinted client mma=
ps
+
+? ? ? 139776 Invalid read in unaligned memcpy with=20
+ Intel compiler v9
+
+
------- Bugs reported and fixed in 3.2.0 ------
=20
SSE3 commits: vx1635,1636, v5997
|
|
From: <sv...@va...> - 2007-01-09 16:47:24
|
Author: sewardj
Date: 2007-01-09 16:47:20 +0000 (Tue, 09 Jan 2007)
New Revision: 6495
Log:
ML_(generic_PRE_sys_mmap): In the case of a hinted mapping (for the
client) which aspacemgr accepts at the hint address but the kernel
declines, try again as a non-hinted mapping. Fixes ld.so mapping
failures observed on ppc32-linux, although the problem potentially
applies to all Linux targets.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.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_syswrap/syswrap-generic.c 2007-01-09 13:24:19 UTC (=
rev 6494)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2007-01-09 16:47:20 UTC (=
rev 6495)
@@ -1888,6 +1888,25 @@
arg4 | VKI_MAP_FIXED,
arg5, arg6);
=20
+ /* A refinement: it may be that the kernel refused aspacem's choice
+ of address. If we were originally asked for a hinted mapping,
+ there is still a last chance: try again at any address.
+ Hence: */
+ if (mreq.rkind =3D=3D MHint && sres.isError) {
+ mreq.start =3D 0;
+ mreq.len =3D arg2;
+ mreq.rkind =3D MAny;
+ advised =3D VG_(am_get_advisory)( &mreq, True/*client*/, &mreq_ok =
);
+ if (!mreq_ok) {
+ /* Our request was bounced, so we'd better fail. */
+ return VG_(mk_SysRes_Error)( VKI_EINVAL );
+ }
+ /* and try again with the kernel */
+ sres =3D VG_(am_do_mmap_NO_NOTIFY)(advised, arg2, arg3,
+ arg4 | VKI_MAP_FIXED,
+ arg5, arg6);
+ }
+
if (!sres.isError) {
/* Notify aspacem and the tool. */
ML_(notify_aspacem_and_tool_of_mmap)(=20
|
|
From: Julian S. <js...@ac...> - 2007-01-09 16:43:16
|
> Paul Mackerras <pa...@sa...> wrote: > > >> This strikes me as strange because the addresses (0xFFFDE000 etc) are > >> almost at the end of 4G. It's also strange because other programs, > >> including large ones, run just fine, and these .so's are mapped quite > >> low, as is normal. > > > > It looks like those libraries have been prelinked on a 64-bit system > > and then moved to a 32-bit system. 32-bit processes get more address > > space (4GB) on a 64-bit machine than an a 32-bit machine (where they > > get either 2GB or 3GB). > > > > However, I would expect the dynamic linker to recover from the mmap > > failure and just retry by mapping the library somewhere else. Paul, Tom, thanks for the analysis. With that info the problem is obvious. V's address space manager has a clear idea of what address ranges it doesn't want the client to use, but it doesn't have a clear idea of what ranges the kernel might refuse. ld.so asks for a hinted mapping at 0xFFFDE000, aspacemgr says "ok by me", ML_(generic_PRE_sys_mmap) duly presents that to the kernel, but now as MAP_FIXED, and the kernel refuses. So the syscall wrapper for mmap hands the failure back to ld.so. My fix is: in ML_(generic_PRE_sys_mmap), if the kernel refuses what was originally a hinted mapping, try again as a non-hinted mapping. That appears to fix the problem. J |
|
From: Tom H. <to...@co...> - 2007-01-09 15:24:37
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> The fact that valgrind is returning ENOMEM will make the dynamic
>> linker think that there really isn't enough memory anywhere in the
>> process space to map the library, so it will give up.
>
> So then it's a bug in m_aspacemgr's handling of hinted mappings that
> can't be placed at the hint address, yes? I better peer at it I suppose.
I think it must be, yes.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2007-01-09 15:20:18
|
Author: sewardj
Date: 2007-01-09 15:20:07 +0000 (Tue, 09 Jan 2007)
New Revision: 1721
Log:
Add 'missing' primop Iop_ReinterpF32asI32 and code generation support
for it on x86 hosts.
Modified:
trunk/priv/host-x86/isel.c
trunk/priv/ir/irdefs.c
trunk/pub/libvex_ir.h
Modified: trunk/priv/host-x86/isel.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/host-x86/isel.c 2007-01-08 06:02:53 UTC (rev 1720)
+++ trunk/priv/host-x86/isel.c 2007-01-09 15:20:07 UTC (rev 1721)
@@ -1143,6 +1143,29 @@
return dst;
}
=20
+ /* ReinterpF32asI32(e) */
+ /* Given an IEEE754 single, produce an I32 with the same bit
+ pattern. Keep stack 8-aligned even though only using 4
+ bytes. */
+ case Iop_ReinterpF32asI32: {
+ HReg rf =3D iselFltExpr(env, e->Iex.Unop.arg);
+ HReg dst =3D newVRegI(env);
+ X86AMode* zero_esp =3D X86AMode_IR(0, hregX86_ESP());
+ /* paranoia */
+ set_FPU_rounding_default(env);
+ /* subl $8, %esp */
+ sub_from_esp(env, 8);
+ /* gstF %rf, 0(%esp) */
+ addInstr(env,
+ X86Instr_FpLdSt(False/*store*/, 4, rf, zero_esp));
+ /* movl 0(%esp), %dst */
+ addInstr(env,=20
+ X86Instr_Alu32R(Xalu_MOV, X86RMI_Mem(zero_esp), dst=
));
+ /* addl $8, %esp */
+ add_to_esp(env, 8);
+ return dst;
+ }
+
case Iop_16to8:
case Iop_32to8:
case Iop_32to16:
Modified: trunk/priv/ir/irdefs.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/ir/irdefs.c 2007-01-08 06:02:53 UTC (rev 1720)
+++ trunk/priv/ir/irdefs.c 2007-01-09 15:20:07 UTC (rev 1721)
@@ -294,6 +294,7 @@
=20
case Iop_ReinterpF64asI64: vex_printf("ReinterpF64asI64"); return;
case Iop_ReinterpI64asF64: vex_printf("ReinterpI64asF64"); return;
+ case Iop_ReinterpF32asI32: vex_printf("ReinterpF32asI32"); return;
case Iop_ReinterpI32asF32: vex_printf("ReinterpI32asF32"); return;
=20
case Iop_I32UtoFx4: vex_printf("Iop_I32UtoFx4"); return;
@@ -1655,6 +1656,7 @@
case Iop_ReinterpI64asF64: UNARY(Ity_I64, Ity_F64);
case Iop_ReinterpF64asI64: UNARY(Ity_F64, Ity_I64);
case Iop_ReinterpI32asF32: UNARY(Ity_I32, Ity_F32);
+ case Iop_ReinterpF32asI32: UNARY(Ity_F32, Ity_I32);
=20
case Iop_AtanF64: case Iop_Yl2xF64: case Iop_Yl2xp1F64:=20
case Iop_ScaleF64: case Iop_PRemF64: case Iop_PRem1F64:
Modified: trunk/pub/libvex_ir.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/pub/libvex_ir.h 2007-01-08 06:02:53 UTC (rev 1720)
+++ trunk/pub/libvex_ir.h 2007-01-09 15:20:07 UTC (rev 1721)
@@ -590,7 +590,7 @@
/* Reinterpretation. Take an F64 and produce an I64 with=20
the same bit pattern, or vice versa. */
Iop_ReinterpF64asI64, Iop_ReinterpI64asF64,
- Iop_ReinterpI32asF32,
+ Iop_ReinterpF32asI32, Iop_ReinterpI32asF32,
=20
/* --- guest x86/amd64 specifics, not mandated by 754. --- */
=20
|
|
From: Julian S. <js...@ac...> - 2007-01-09 15:09:32
|
> The fact that valgrind is returning ENOMEM will make the dynamic > linker think that there really isn't enough memory anywhere in the > process space to map the library, so it will give up. So then it's a bug in m_aspacemgr's handling of hinted mappings that can't be placed at the hint address, yes? I better peer at it I suppose. J |
|
From: <sv...@va...> - 2007-01-09 13:24:21
|
Author: njn
Date: 2007-01-09 13:24:19 +0000 (Tue, 09 Jan 2007)
New Revision: 6494
Log:
Don't search for origins if --undef-origins=3Dno.
Modified:
branches/ORIGIN_TRACKING/memcheck/mc_main.c
branches/ORIGIN_TRACKING/memcheck/mc_translate.c
Modified: branches/ORIGIN_TRACKING/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/ORIGIN_TRACKING/memcheck/mc_main.c 2007-01-09 13:10:12 UTC (=
rev 6493)
+++ branches/ORIGIN_TRACKING/memcheck/mc_main.c 2007-01-09 13:24:19 UTC (=
rev 6494)
@@ -36,7 +36,6 @@
// - do timings, to work out how much slow-down it causes. Specialise
// the helperc functions some if possible. Work out if checking
// clo_undef_origins frequently slows things down much.
-// - unbreak various regtests
=20
#include "pub_tool_basics.h"
#include "pub_tool_aspacemgr.h"
Modified: branches/ORIGIN_TRACKING/memcheck/mc_translate.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/ORIGIN_TRACKING/memcheck/mc_translate.c 2007-01-09 13:10:12 =
UTC (rev 6493)
+++ branches/ORIGIN_TRACKING/memcheck/mc_translate.c 2007-01-09 13:24:19 =
UTC (rev 6494)
@@ -903,8 +903,9 @@
OriginsList worklist_actual, *worklist =3D &worklist_actual;
Int i =3D mce->bb_in_i - 1;
=20
- // Don't do all this work if we're not reporting undefined value erro=
rs.
- if (!MC_(clo_undef_value_errors))
+ // Don't do all this work if we're not reporting undefined value erro=
rs
+ // or undefined value error origins.
+ if (!MC_(clo_undef_value_errors) || !MC_(clo_undef_origins))
return;
=20
init_OriginsList(worklist);
|
|
From: <sv...@va...> - 2007-01-09 13:10:20
|
Author: njn
Date: 2007-01-09 13:10:12 +0000 (Tue, 09 Jan 2007)
New Revision: 6493
Log:
Handle a few extra cases where origin sizes and the word size don't match=
.
And update the expected output for pushfpopf. All the regtests now work =
the
same on my machine as in the trunk.
Modified:
branches/ORIGIN_TRACKING/memcheck/mc_translate.c
branches/ORIGIN_TRACKING/memcheck/tests/x86/pushfpopf.stderr.exp
Modified: branches/ORIGIN_TRACKING/memcheck/mc_translate.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/ORIGIN_TRACKING/memcheck/mc_translate.c 2007-01-08 06:43:25 =
UTC (rev 6492)
+++ branches/ORIGIN_TRACKING/memcheck/mc_translate.c 2007-01-09 13:10:12 =
UTC (rev 6493)
@@ -1158,28 +1158,87 @@
n_origins_found =3D originTmps.tmps_nextfree;
}
=20
- // foreach (t) in finish_list {
- // 32-bit machines:
- // if (4 =3D=3D sizeof(t)) --> use t
- // if (8 =3D=3D sizeof(t)) --> use Iop_64HIto32(t) // pass in =
high word
- //=20
- // 64-bit machines:
- // if (4 =3D=3D sizeof(t)) --> use Iop(32HLto64)(0, t)
- // if (8 =3D=3D sizeof(t)) --> use t
- // }
+ // Here we pass in one 32-bit origin per word. Even on 64-bit machin=
es
+ // -- we extend the 32-bit origin to be 64-bits.
+ tl_assert(4 =3D=3D VG_WORDSIZE || 8 =3D=3D VG_WORDSIZE);
+
for (j =3D 0; j < n_origins_found; j++) {
- IRTemp tmp =3D originTmps.tmps[j];
- Int tmp_szB =3D sizeofIRType(typeOfIRTemp(mce->bb_in->tyenv, tm=
p));
- // XXX: in the 16=3D=3Dtmp_szB case, convert using Iop_128HIto64, =
then
- // Iop_64HIto32
- if (8 =3D=3D tmp_szB && 4 =3D=3D VG_WORDSIZE) {
- //convert using Iop_64HIto32, rename in the originTmps array
- tl_assert2(0, "XXX: 64-bit operand, not yet handled");
- } else if (4 =3D=3D tmp_szB && 8 =3D=3D VG_WORDSIZE) {
- // convert using Iop_32HLto64, rename in the originTmps array
- tl_assert2(0, "XXX: 32-bit operand on 64-bit $PLAT, not yet han=
dled");
- } else {
- tl_assert(VG_WORDSIZE =3D=3D tmp_szB);
+ IRTemp tX =3D originTmps.tmps[j];
+ IRType tX_ty =3D typeOfIRTemp(mce->bb_in->tyenv, tX);
+
+ switch (tX_ty) {
+ case Ity_I32:
+ if (4 =3D=3D VG_WORDSIZE) {
+ // Word-size, ok to pass as-is: do nothing
+ } else {
+ // XXX
+ // convert using Iop_32HLto64, rename in the originTmps arra=
y
+ tl_assert2(0, "XXX: I32 tmp on 64-bit $PLAT, not yet handled=
");
+ }
+ break;
+
+ case Ity_F32:
+ if (4 =3D=3D VG_WORDSIZE) {
+ // tX is an F32, add "tY =3D ReinterpF32asI32(tX)", rename t=
X as
+ // tY in originTmps.
+ IRTemp tY =3D newIRTemp(mce->bb_out->tyenv, Ity_I32);
+ IRExpr* expr =3D unop(Iop_ReinterpF32asI32, mkexpr(tX));
+ assign( mce->bb_out, tY, expr );
+ originTmps.tmps[j] =3D tY;
+ } else {
+ // Need to reinterpF32asI32, then use 32HLto64 to zero-exten=
d,
+ // and rename in the originTmps array.
+ tl_assert2(0, "XXX: F32 tmp on 64-bit $PLAT, not yet handled=
");
+ }
+ break;
+
+ case Ity_I64:
+ if (8 =3D=3D VG_WORDSIZE) {
+ // Word-sized, ok to pass as-is: do nothing
+ } else {
+ // XXX: when this occurs, try the code below (which should w=
ork)
+ // by removing the assertion.
+ // tX is an I64, add "tY =3D 64HIto32(tX)", rename tX as
+ // tY in originTmps.
+ IRTemp tY =3D newIRTemp(mce->bb_out->tyenv, Ity_I32);
+ IRExpr* expr =3D unop(Iop_64HIto32, mkexpr(tX));
+ assign( mce->bb_out, tY, expr );
+ originTmps.tmps[j] =3D tY;
+ }
+ break;
+
+ case Ity_F64:
+ if (8 =3D=3D VG_WORDSIZE) {
+ // XXX: when this occurs, try the code below (which should w=
ork)
+ // by removing this assertion.
+ // tX is an F64, add "tY =3D ReinterpF64asI64(tX)", rename t=
X as
+ // tY in originTmps.
+ IRTemp tY =3D newIRTemp(mce->bb_out->tyenv, Ity_I64);
+ IRExpr* expr =3D unop(Iop_ReinterpF64asI64, mkexpr(tX));
+ assign( mce->bb_out, tY, expr );
+ originTmps.tmps[j] =3D tY;
+ tl_assert2(0, "XXX: F64 on 64-bit, not yet handled");
+ } else {
+ // tX is an F64, add:
+ // tY =3D ReinterpF64asI64(tX)
+ // tZ =3D 64HIto32(tY)
+ // and rename tX as tZ in originTmps.
+ IRTemp tY =3D newIRTemp(mce->bb_out->tyenv, Ity_I64);
+ IRTemp tZ =3D newIRTemp(mce->bb_out->tyenv, Ity_I32);
+ IRExpr* expr1 =3D unop(Iop_ReinterpF64asI64, mkexpr(tX));
+ IRExpr* expr2 =3D unop(Iop_64HIto32, mkexpr(tY));
+ assign( mce->bb_out, tY, expr1 );
+ assign( mce->bb_out, tZ, expr2 );
+ originTmps.tmps[j] =3D tZ;
+ }
+ break;
+
+ default:
+ // XXX: I1, I8, I16, I128, F32, F64, V128
+ // XXX: in the 16=3D=3Dtmp_szB case, convert using Iop_128HIto6=
4, then
+ // Iop_64HIto32
+ ppIRType(tX_ty);
+ tl_assert2(0, "complainIfUndefined: unhandled type");
}
}
=20
Modified: branches/ORIGIN_TRACKING/memcheck/tests/x86/pushfpopf.stderr.ex=
p
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/ORIGIN_TRACKING/memcheck/tests/x86/pushfpopf.stderr.exp 2007=
-01-08 06:43:25 UTC (rev 6492)
+++ branches/ORIGIN_TRACKING/memcheck/tests/x86/pushfpopf.stderr.exp 2007=
-01-09 13:10:12 UTC (rev 6493)
@@ -1,7 +1,9 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: fooble (...)
by 0x........: main (pushfpopf_c.c:12)
+ Uninitialised value has unknown origin
=20
Conditional jump or move depends on uninitialised value(s)
at 0x........: fooble (...)
by 0x........: main (pushfpopf_c.c:12)
+ Uninitialised value has unknown origin
|
|
From: Tom H. <to...@co...> - 2007-01-09 08:41:24
|
In message <178...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Julian Seward writes:
>
>> V starts up OK and loads /bin/bash and its ELF interpreter as usual, and
>> starts it. However, at some point ld.so is doing some fixed mmaps for the
>> 3 .so's mentioned above, and these are failing:
>>
>> sys_mmap ( 0xFFFDE000, 69636, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC)
>> sys_mmap ( 0xFFFD9000, 90236, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC)
>> sys_mmap ( 0xFFFA1000, 319664, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC)
>>
>> This strikes me as strange because the addresses (0xFFFDE000 etc) are almost
>> at the end of 4G. It's also strange because other programs, including large
>> ones, run just fine, and these .so's are mapped quite low, as is normal.
>
> It looks like those libraries have been prelinked on a 64-bit system
> and then moved to a 32-bit system. 32-bit processes get more address
> space (4GB) on a 64-bit machine than an a 32-bit machine (where they
> get either 2GB or 3GB).
>
> However, I would expect the dynamic linker to recover from the mmap
> failure and just retry by mapping the library somewhere else.
> Strange.
That's not how prelinking handles failures. If you look at those mmap
calls you will see that although there is an address given, the flags
do not include MAP_FIXED so the address is only a hint.
What mmap is supposed to do is that if it can't use the supplied
address then it should just choose another one at random. The dynamic
linker will then notice that the mapping didn't happen at the
prelinked address and do the relocations to fix things up.
The fact that valgrind is returning ENOMEM will make the dynamic
linker think that there really isn't enough memory anywhere in the
process space to map the library, so it will give up.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <js...@ac...> - 2007-01-09 06:42:47
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-01-09 09: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 == 217 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Paul M. <pa...@sa...> - 2007-01-09 05:32:49
|
Julian Seward writes: > V starts up OK and loads /bin/bash and its ELF interpreter as usual, and > starts it. However, at some point ld.so is doing some fixed mmaps for the > 3 .so's mentioned above, and these are failing: > > sys_mmap ( 0xFFFDE000, 69636, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) > sys_mmap ( 0xFFFD9000, 90236, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) > sys_mmap ( 0xFFFA1000, 319664, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) > > This strikes me as strange because the addresses (0xFFFDE000 etc) are almost > at the end of 4G. It's also strange because other programs, including large > ones, run just fine, and these .so's are mapped quite low, as is normal. It looks like those libraries have been prelinked on a 64-bit system and then moved to a 32-bit system. 32-bit processes get more address space (4GB) on a 64-bit machine than an a 32-bit machine (where they get either 2GB or 3GB). However, I would expect the dynamic linker to recover from the mmap failure and just retry by mapping the library somewhere else. Strange. Paul. |
|
From: <js...@ac...> - 2007-01-09 05:16:12
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2007-01-09 04: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 == 250 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Results from 24 hours ago == ================================================= 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 == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jan 9 04:55:05 2007 --- new.short Tue Jan 9 05:16:29 2007 *************** *** 10,12 **** ! == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) --- 10,12 ---- ! == 250 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) *************** *** 18,19 **** --- 18,20 ---- none/tests/mremap2 (stdout) + none/tests/pth_detached (stdout) |
|
From: Tom H. <to...@co...> - 2007-01-09 03:55:04
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2007-01-09 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 == 252 tests, 5 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2007-01-09 03:24:14
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-01-09 03:15:02 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccoZXtcd.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccoZXtcd.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.12949/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.12949/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.12949/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.12949/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.12949/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccpLbSo8.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccpLbSo8.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.12949/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.12949/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.12949/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.12949/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.12949/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jan 9 03:19:33 2007 --- new.short Tue Jan 9 03:24:03 2007 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccpLbSo8.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccpLbSo8.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccoZXtcd.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccoZXtcd.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2007-01-09 03:23:18
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2007-01-09 03:10:04 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 == 281 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 281 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jan 9 03:16:39 2007 --- new.short Tue Jan 9 03:23:05 2007 *************** *** 8,10 **** ! == 281 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 281 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 14,16 **** none/tests/mremap2 (stdout) - none/tests/pth_detached (stdout) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2007-01-09 03:17:34
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-01-09 03:05: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 == 281 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-01-09 03:14:37
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-01-09 03: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 == 283 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-01-09 01:16:16
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-01-09 02:00:01 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 == 223 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |