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
(6) |
2
(3) |
3
(2) |
4
(1) |
5
(1) |
6
(6) |
7
(9) |
|
8
(8) |
9
(6) |
10
(13) |
11
(9) |
12
(12) |
13
(6) |
14
(1) |
|
15
(4) |
16
(8) |
17
(15) |
18
(7) |
19
(3) |
20
(11) |
21
(7) |
|
22
(26) |
23
(7) |
24
(4) |
25
(9) |
26
(10) |
27
(13) |
28
(6) |
|
29
(11) |
30
(6) |
31
(8) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2010-08-12 15:54:05
|
On Thursday, August 12, 2010, Maynard Johnson wrote:
> On 01/20/2010 1:49 PM, Maynard Johnson wrote:
> > Maynard Johnson wrote:
> >> The attached patch addresses a problem that I reported to this list on
> >> Jan 4. Julian suggested the fix, so my patch integrates his suggestion
> >> into the failing testcases' source files.
> >>
> >> Problem description: Upon a call to a function, some architectures store
> >> pointers into into registers. Valgrind may consider these registers when
> >> determining whether an address is reachable, so we need to zero-out
> >> these registers as needed. This patch addresses the problem only for
> >> PowerPC, but the implementation for other architectures can be easily
> >> added when necessary.
> >
> > Julian, any comments on this patch?
>
> Julian,
> Since this patch submission seems to have fallen through the cracks, would
> you like me to open a bug report for this?
Yes. Please do.
J
>
> -Maynard
>
> > Thanks.
> > -Maynard
> > _______________________________________________________________
> >
> >> diff -paur valgrind-3.5.0/memcheck/tests/leak-cases.c
> >> valg-350-fix/memcheck/tests/leak-cases.c
> >> --- valgrind-3.5.0/memcheck/tests/leak-cases.c 2009-08-19
> >> 08:37:00.000000000 -0500
> >> +++ valg-350-fix/memcheck/tests/leak-cases.c 2010-01-11
> >> 15:53:43.000000000 -0600 @@ -106,6 +106,7 @@ int main(void)
> >> // counting in main() avoids the problem.
> >> f();
> >>
> >> + clear_caller_saved_regs();
> >> GET_FINAL_LEAK_COUNTS;
> >>
> >> PRINT_LEAK_COUNTS(stderr);
> >> diff -paur valgrind-3.5.0/memcheck/tests/leak-cycle.c
> >> valg-350-fix/memcheck/tests/leak-cycle.c
> >> --- valgrind-3.5.0/memcheck/tests/leak-cycle.c 2009-08-19
> >> 08:37:00.000000000 -0500
> >> +++ valg-350-fix/memcheck/tests/leak-cycle.c 2010-01-11
> >> 15:51:52.000000000 -0600 @@ -68,6 +68,8 @@ int main()
> >>
> >> c1 = c2 = 0;
> >>
> >> + clear_caller_saved_regs();
> >> +
> >> GET_FINAL_LEAK_COUNTS;
> >>
> >> PRINT_LEAK_COUNTS(stderr);
> >> diff -paur valgrind-3.5.0/memcheck/tests/leak.h
> >> valg-350-fix/memcheck/tests/leak.h
> >> --- valgrind-3.5.0/memcheck/tests/leak.h 2009-08-19 08:36:59.000000000
> >> -0500 +++ valg-350-fix/memcheck/tests/leak.h 2010-01-11
> >> 15:51:32.000000000 -0600 @@ -41,3 +41,30 @@
> >> S_bytes,S_blocks); \
> >> } while (0)
> >>
> >> +/* Upon a call to a function, some architectures store pointers into
> >> + * into registers. Valgrind may consider these registers when
> >> determining + * whether an address is reachable, so we need to zero-out
> >> these registers + * as needed.
> >> + */
> >> +
> >> +#if defined __powerpc__
> >> +void inline clear_caller_saved_regs(void)
> >> +{
> >> + __asm__ __volatile__( "li 3, 0" : : :/*trash*/"r3" );
> >> + __asm__ __volatile__( "li 4, 0" : : :/*trash*/"r4" );
> >> + __asm__ __volatile__( "li 5, 0" : : :/*trash*/"r5" );
> >> + __asm__ __volatile__( "li 6, 0" : : :/*trash*/"r6" );
> >> + __asm__ __volatile__( "li 7, 0" : : :/*trash*/"r7" );
> >> + __asm__ __volatile__( "li 8, 0" : : :/*trash*/"r8" );
> >> + __asm__ __volatile__( "li 9, 0" : : :/*trash*/"r9" );
> >> + __asm__ __volatile__( "li 10, 0" : : :/*trash*/"r10" );
> >> + __asm__ __volatile__( "li 11, 0" : : :/*trash*/"r11" );
> >> + __asm__ __volatile__( "li 12, 0" : : :/*trash*/"r12" );
> >> +}
> >> +#else
> >> +void inline clear_caller_saved_regs(void)
> >> +{
> >> +}
> >> +#endif
> >> +
> >> +
>
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Maynard J. <may...@us...> - 2010-08-12 15:20:24
|
On 01/20/2010 1:49 PM, Maynard Johnson wrote:
> Maynard Johnson wrote:
>> The attached patch addresses a problem that I reported to this list on Jan 4.
>> Julian suggested the fix, so my patch integrates his suggestion into the
>> failing testcases' source files.
>>
>> Problem description: Upon a call to a function, some architectures store
>> pointers into into registers. Valgrind may consider these registers when
>> determining whether an address is reachable, so we need to zero-out these
>> registers as needed. This patch addresses the problem only for PowerPC, but
>> the implementation for other architectures can be easily added when necessary.
>
> Julian, any comments on this patch?
Julian,
Since this patch submission seems to have fallen through the cracks, would you
like me to open a bug report for this?
-Maynard
>
> Thanks.
> -Maynard
> _______________________________________________________________
>
>> diff -paur valgrind-3.5.0/memcheck/tests/leak-cases.c
>> valg-350-fix/memcheck/tests/leak-cases.c
>> --- valgrind-3.5.0/memcheck/tests/leak-cases.c 2009-08-19 08:37:00.000000000
>> -0500
>> +++ valg-350-fix/memcheck/tests/leak-cases.c 2010-01-11 15:53:43.000000000 -0600
>> @@ -106,6 +106,7 @@ int main(void)
>> // counting in main() avoids the problem.
>> f();
>>
>> + clear_caller_saved_regs();
>> GET_FINAL_LEAK_COUNTS;
>>
>> PRINT_LEAK_COUNTS(stderr);
>> diff -paur valgrind-3.5.0/memcheck/tests/leak-cycle.c
>> valg-350-fix/memcheck/tests/leak-cycle.c
>> --- valgrind-3.5.0/memcheck/tests/leak-cycle.c 2009-08-19 08:37:00.000000000
>> -0500
>> +++ valg-350-fix/memcheck/tests/leak-cycle.c 2010-01-11 15:51:52.000000000 -0600
>> @@ -68,6 +68,8 @@ int main()
>>
>> c1 = c2 = 0;
>>
>> + clear_caller_saved_regs();
>> +
>> GET_FINAL_LEAK_COUNTS;
>>
>> PRINT_LEAK_COUNTS(stderr);
>> diff -paur valgrind-3.5.0/memcheck/tests/leak.h
>> valg-350-fix/memcheck/tests/leak.h
>> --- valgrind-3.5.0/memcheck/tests/leak.h 2009-08-19 08:36:59.000000000 -0500
>> +++ valg-350-fix/memcheck/tests/leak.h 2010-01-11 15:51:32.000000000 -0600
>> @@ -41,3 +41,30 @@
>> S_bytes,S_blocks); \
>> } while (0)
>>
>> +/* Upon a call to a function, some architectures store pointers into
>> + * into registers. Valgrind may consider these registers when determining
>> + * whether an address is reachable, so we need to zero-out these registers
>> + * as needed.
>> + */
>> +
>> +#if defined __powerpc__
>> +void inline clear_caller_saved_regs(void)
>> +{
>> + __asm__ __volatile__( "li 3, 0" : : :/*trash*/"r3" );
>> + __asm__ __volatile__( "li 4, 0" : : :/*trash*/"r4" );
>> + __asm__ __volatile__( "li 5, 0" : : :/*trash*/"r5" );
>> + __asm__ __volatile__( "li 6, 0" : : :/*trash*/"r6" );
>> + __asm__ __volatile__( "li 7, 0" : : :/*trash*/"r7" );
>> + __asm__ __volatile__( "li 8, 0" : : :/*trash*/"r8" );
>> + __asm__ __volatile__( "li 9, 0" : : :/*trash*/"r9" );
>> + __asm__ __volatile__( "li 10, 0" : : :/*trash*/"r10" );
>> + __asm__ __volatile__( "li 11, 0" : : :/*trash*/"r11" );
>> + __asm__ __volatile__( "li 12, 0" : : :/*trash*/"r12" );
>> +}
>> +#else
>> +void inline clear_caller_saved_regs(void)
>> +{
>> +}
>> +#endif
>> +
>> +
>>
>>
>
|
|
From: Maynard J. <may...@us...> - 2010-08-12 14:35:40
|
On 08/12/2010 3:44 AM, Julian Seward wrote: > > Maynard, thanks for the patch. > > Please could you open a bug report and attach the patches, including > the test programs, to the bug report. Patches sent to the mailing list > are at (serious) risk of falling through the cracks and disappearing. > Also, putting patches in the bug tracker gives a single URL at which > we can point anybody interested. Julian, Thanks for the reply. I opened a bug report as you asked: https://bugs.kde.org/show_bug.cgi?id=247526. -Maynard > > See http://www.valgrind.org/support/bug_reports.html for directions > on filing bug reports. > > J > > On Wednesday, August 11, 2010, Maynard Johnson wrote: >> On 08/11/2010 10:38 AM, Maynard Johnson wrote: >>> On 08/10/2010 2:36 PM, Maynard Johnson wrote: >>>> Bart Van Assche wrote: >>>>> On Tue, Aug 10, 2010 at 5:59 PM, Maynard Johnson<may...@us...> > wrote: >>>>>> Bart Van Assche wrote: >>>>>>> On Mon, Aug 9, 2010 at 11:59 PM, Maynard > Johnson<may...@us...>wrote: >>>>>>>> Currently, Valgrind has only partial support for new IBM POWER6 >>>>>>>> instructions (as defined in >>>>>>>> http://www.power.org/resources/reading/PowerISA_V2.05.pdf). The >>>>>>>> attached patch completes the 2.05 support. >>>>>>>> >>>>>>>> The results of running 'make regtest' on a POWER6 box are almost >>>>>>>> identical before and after applying this patch -- about 50 failing >>>>>>>> testcases. I have looked into many of those failing testcases and, >>>>>>>> so far, have been able to cut the number of failures to less than >>>>>>>> half that. I have a separate testsuite patch that I will submit >>>>>>>> separately (upon request, or I'll wait until this patch is >>>>>>>> accepted) that provides the improved testsuite results. >>>>>>>> >>>>>>>> Review comments are welcome. >>> >>> The attached "version 2" patch fixes the formatting issues that Bart >>> pointed out, plus a couple other minor nits I found while scrubbing it. >>> This patch was made against a snapshot of today's SVN repository. But as >>> I mentioned earlier to Bart, applying the patch will result in an >>> expected failure involving none/tests/ppc64/jm-insns.c, since this file >>> is symbolically linked to none/tests/ppc32/jm-insns.c, which is patched >>> earlier on during the patch application. Just hit "Enter" twice to >>> ignore that failure, and the rest of the patch should apply cleanly. >> >> Another thing I should have mentioned . . . This patch contains some new >> shell scripts which need to be changed to executable before attempting to >> run the testsuite. These new script files are: >> - memcheck/tests/ppc32/filter_stderr >> - memcheck/tests/ppc64/filter_stderr >> - none/tests/ppc32/check_vmx_cap >> - none/tests/ppc64/check_vmx_cap >> >> -Maynard >> >>> Thanks. >>> -Maynard >>> >>> >>> >>> ------------------------------------------------------------------------- >>> ----- This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> >>> >>> >>> _______________________________________________ >>> Valgrind-developers mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> >> --------------------------------------------------------------------------- >> --- This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: <sv...@va...> - 2010-08-12 13:30:11
|
Author: sewardj
Date: 2010-08-12 14:30:02 +0100 (Thu, 12 Aug 2010)
New Revision: 11257
Log:
Another supp for OSX 10.5.
Modified:
trunk/darwin9.supp
Modified: trunk/darwin9.supp
===================================================================
--- trunk/darwin9.supp 2010-08-12 07:48:27 UTC (rev 11256)
+++ trunk/darwin9.supp 2010-08-12 13:30:02 UTC (rev 11257)
@@ -180,6 +180,13 @@
fun:vsnprintf
}
+{
+ macos-TFontFeatures::TFontFeatures(unsigned long)-uninitialised-stack-val
+ Memcheck:Cond
+ fun:_ZN13TFontFeaturesC2Em
+ fun:_ZNK9TBaseFont12CopyFeaturesEv
+}
+
##----------------------------------------------------------------------##
# Helgrind
##----------------------------------------------------------------------##
|
|
From: Alexander P. <gl...@go...> - 2010-08-12 11:59:34
|
On Thu, Aug 12, 2010 at 1:03 PM, Julian Seward <js...@ac...> wrote: > >> > Does anyone have any insight about this? > > Not me. Do you have a potential patch? Not yet > Is this being tracked on the > bug tracker? It now is, see https://bugs.kde.org/show_bug.cgi?id=247510 > > J > > On Monday, August 09, 2010, Alexander Potapenko wrote: >> Found this in coregrind/m_syswrap/syswrap-darwin.c: >> ======================================= >> PRE(chmod_extended) >> { >> /* DDD: Note: this is not really correct. Handling of >> fchmod_extended is broken in the same way. */ >> PRINT("chmod_extended ( %#lx(%s), %ld, %ld, %ld, %#lx )", >> ARG1, ARG1 ? (HChar*)ARG1 : "(null)", ARG2, ARG3, ARG4, ARG5); >> PRE_REG_READ5(long, "chmod", >> unsigned int, fildes, >> uid_t, uid, >> gid_t, gid, >> vki_mode_t, mode, >> void* /*really,user_addr_t*/, xsecurity); >> PRE_MEM_RASCIIZ("chmod_extended(path)", ARG1); >> /* DDD: relative to the xnu sources (kauth_copyinfilesec), this >> is just way wrong. [The trouble is with the size, which depends on a >> non-trival kernel computation] */ >> PRE_MEM_READ( "chmod_extended(xsecurity)", ARG5, >> sizeof(struct vki_kauth_filesec) ); >> } >> ======================================= >> >> As I understand, the size of the last argument of [f]chmod_extended >> may vary on 10.5. Is it still so on 10.6? >> >> On Mon, Aug 9, 2010 at 4:13 PM, Alexander Potapenko <gl...@go...> > wrote: >> > Hi all, >> > >> > I'm getting the following reports while running some Chromium >> > unittests under Memcheck on OS X 10.6: >> > >> > =================================== >> > Syscall param fchmod_extended(xsecurity) points to unaddressable byte(s) >> > __fchmod_extended >> > fchmodx_np >> > copyfile_internal >> > copyfile >> > file_util::CopyFile(FilePath const&, FilePath const&) >> > (/Users/glider/src/chromium/src/base/file_util_mac.mm:30) >> > >> > Syscall param chmod_extended(xsecurity) points to unaddressable byte(s) >> > __chmod_extended >> > chmodx_np >> > copyfile >> > file_util::CopyFile(FilePath const&, FilePath const&) >> > (/Users/glider/src/chromium/src/base/file_util_mac.mm:30) >> > =================================== >> > >> > When I run dtruss on these tests I find out that the syscalls are >> > invoked with almost no arguments: >> > chmod_extended(0x1330000, 0x0, 0x0, 0x0, 0x0) and >> > fchmod_extended(0x5, 0x0, 0x0, 0x0, 0x0) >> > , where 0x5 is a valid file descriptor (it's used by other syscalls) >> > and 0x1330000 is a valid string (ditto). >> > >> > I suspect the reports are caused by some harmless optimization which >> > was not used in 10.5 but appeared in 10.6. >> > Does anyone have any insight about this? >> > >> > Thanks in advance, >> > Alexander Potapenko >> > Software Engineer >> > Google Moscow > > -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Julian S. <js...@ac...> - 2010-08-12 11:32:21
|
It needs a configure-time check, which stops the build system building this test on processors which don't support this instruction (or, more correctly, on systems where the assembler hasn't heard of the instruction). There are already some checks like that for SSSE3 et in configure.in. I planned to add such a check at the time the SSE4.2 support got finalized/enabled. J On Sunday, August 08, 2010, Rich Coe wrote: > Hi Julian, > > I was looking into why my mac build 'make check' was failing, and after > building configure with '--enable-only32bit' I came accross this failure. > > gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include > -I../../../coregrind -I../../../include -I../../../VEX/pub -DVGA_x86=1 > -DVGO_darwin=1 -DVGP_x86_darwin=1 -Winline -Wall -Wshadow -g -m32 -mmmx > -msse -mdynamic-no-pic -Wno-long-long -Wno-pointer-sign > -fno-stack-protector -MT lzcnt32.o -MD -MP -MF .deps/lzcnt32.Tpo -c -o > lzcnt32.o lzcnt32.c /var/tmp//cctKq6ZT.s:51:no such instruction: `lzcntl > 0(%eax), %esi' /var/tmp//cctKq6ZT.s:93:no such instruction: `lzcntw > 0(%eax), %si' make[5]: *** [lzcnt32.o] Error 1 > rm insn_ssse3.c insn_sse3.c insn_fpu.c insn_sse.c insn_mmx.c insn_mmxext.c > insn_sse2.c insn_basic.c insn_cmov.c make[4]: *** [check-am] Error 2 > > > Here is the uname string: > Darwin minimes-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 > 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 > > Rich |
|
From: Nicholas N. <n.n...@gm...> - 2010-08-12 09:35:43
|
Nightly build on ocean ( Ubuntu 9.10, x86_64 )
Started at 2010-08-12 02:00:01 PDT
Ended at 2010-08-12 02:35:29 PDT
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
== 552 tests, 7 stderr failures, 4 stdout failures, 0 post failures ==
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/long_namespace_xml (stderr)
none/tests/amd64/bug132918 (stdout)
none/tests/amd64/fxtract (stdout)
none/tests/x86/fxtract (stdout)
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc09_bad_unlock (stderr)
helgrind/tests/tc20_verifywrap (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
drd/tests/pth_detached2 (stdout)
exp-ptrcheck/tests/bad_percentify (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
== 552 tests, 7 stderr failures, 3 stdout failures, 0 post failures ==
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/long_namespace_xml (stderr)
none/tests/amd64/bug132918 (stdout)
none/tests/amd64/fxtract (stdout)
none/tests/x86/fxtract (stdout)
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc09_bad_unlock (stderr)
helgrind/tests/tc20_verifywrap (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
exp-ptrcheck/tests/bad_percentify (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short 2010-08-12 02:17:55.000000000 -0700
--- new.short 2010-08-12 02:35:29.000000000 -0700
***************
*** 8,10 ****
! == 552 tests, 7 stderr failures, 3 stdout failures, 0 post failures ==
memcheck/tests/linux/stack_switch (stderr)
--- 8,10 ----
! == 552 tests, 7 stderr failures, 4 stdout failures, 0 post failures ==
memcheck/tests/linux/stack_switch (stderr)
***************
*** 18,19 ****
--- 18,20 ----
helgrind/tests/tc23_bogus_condwait (stderr)
+ drd/tests/pth_detached2 (stdout)
exp-ptrcheck/tests/bad_percentify (stderr)
=================================================
./valgrind-new/drd/tests/pth_detached2.stdout.diff
=================================================
--- pth_detached2.stdout.exp 2010-08-12 02:19:19.000000000 -0700
+++ pth_detached2.stdout.out 2010-08-12 02:32:35.000000000 -0700
@@ -1 +1 @@
-....................
+...................
=================================================
./valgrind-new/exp-ptrcheck/tests/bad_percentify.stderr.diff-glibc28-amd64
=================================================
--- bad_percentify.stderr.exp-glibc28-amd64 2010-08-12 02:18:15.000000000 -0700
+++ bad_percentify.stderr.out 2010-08-12 02:34:14.000000000 -0700
@@ -1,32 +1,29 @@
Invalid read of size 1
- at 0x........: strlen (h_intercepts.c:...)
- by 0x........: ...
+ at 0x........: ...
by 0x........: ...
by 0x........: VG_print_translation_stats (bad_percentify.c:88)
by 0x........: main (bad_percentify.c:107)
Address 0x........ expected vs actual:
- Expected: stack array "buf" in frame 3 back from here
+ Expected: stack array "buf" in frame 2 back from here
Actual: unknown
Invalid read of size 1
- at 0x........: strlen (h_intercepts.c:...)
- by 0x........: ...
+ at 0x........: ...
by 0x........: ...
by 0x........: VG_print_translation_stats (bad_percentify.c:93)
by 0x........: main (bad_percentify.c:107)
Address 0x........ expected vs actual:
- Expected: stack array "buf" in frame 3 back from here
+ Expected: stack array "buf" in frame 2 back from here
Actual: unknown
Invalid read of size 1
- at 0x........: strlen (h_intercepts.c:...)
- by 0x........: ...
+ at 0x........: ...
by 0x........: ...
by 0x........: VG_print_translation_stats (bad_percentify.c:98)
by 0x........: main (bad_percentify.c:107)
Address 0x........ expected vs actual:
- Expected: stack array "buf" in frame 3 back from here
+ Expected: stack array "buf" in frame 2 back from here
Actual: unknown
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2010-08-12 02:18:11.000000000 -0700
+++ tc06_two_races_xml.stderr.out 2010-08-12 02:29:45.000000000 -0700
@@ -40,16 +40,25 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
+ <fn>T.102</fn>
+ <dir>...</dir>
+ <file>createthread.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>pthread_create@@GLIBC_2.2.5</fn>
+ <dir>...</dir>
+ <file>createthread.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
@@ -121,11 +130,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat>
@@ -175,11 +190,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat>
@@ -229,11 +250,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot2"</auxwhat>
@@ -283,11 +310,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<truncated beyond 100 lines>
=================================================
./valgrind-new/helgrind/tests/tc09_bad_unlock.stderr.diff-glibc23-amd64
=================================================
--- tc09_bad_unlock.stderr.exp-glibc23-amd64 2010-08-12 02:18:11.000000000 -0700
+++ tc09_bad_unlock.stderr.out 2010-08-12 02:29:48.000000000 -0700
@@ -31,14 +31,13 @@
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:49)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:49)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
+Thread #x's call to pthread_mutex_unlock failed
+ with error code 22 (EINVAL: Invalid argument)
+ at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:49)
+---------------------
Thread #x unlocked a not-locked lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:27)
@@ -46,6 +45,20 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:23)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Attempt to re-lock a non-recursive lock I already hold
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:50)
+ Lock was previously acquired
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
by 0x........: main (tc09_bad_unlock.c:50)
Thread #x was created
@@ -62,20 +75,21 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:50)
+ by 0x........: main (tc09_bad_unlock.c:49)
Thread #x unlocked an invalid lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:50)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:50)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
+Thread #x's call to pthread_mutex_unlock failed
+ with error code 22 (EINVAL: Invalid argument)
+ at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:50)
+Thread #x: Exiting thread still holds 1 lock
+ ...
+
-ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/helgrind/tests/tc09_bad_unlock.stderr.diff-glibc25-amd64
=================================================
--- tc09_bad_unlock.stderr.exp-glibc25-amd64 2010-08-12 02:18:11.000000000 -0700
+++ tc09_bad_unlock.stderr.out 2010-08-12 02:29:48.000000000 -0700
@@ -51,6 +51,10 @@
at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:32)
by 0x........: main (tc09_bad_unlock.c:50)
+ Lock was previously acquired
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:49)
Thread #x: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
=================================================
./valgrind-new/helgrind/tests/tc09_bad_unlock.stderr.diff-glibc25-x86
=================================================
--- tc09_bad_unlock.stderr.exp-glibc25-x86 2010-08-12 02:18:11.000000000 -0700
+++ tc09_bad_unlock.stderr.out 2010-08-12 02:29:48.000000000 -0700
@@ -37,14 +37,7 @@
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:49)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:49)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:49)
-
+---------------------
Thread #x unlocked a not-locked lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:27)
@@ -52,6 +45,20 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:23)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Attempt to re-lock a non-recursive lock I already hold
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:50)
+ Lock was previously acquired
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
by 0x........: main (tc09_bad_unlock.c:50)
Thread #x was created
@@ -68,7 +75,7 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:50)
+ by 0x........: main (tc09_bad_unlock.c:49)
Thread #x unlocked an invalid lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
@@ -81,13 +88,8 @@
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:50)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:50)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:50)
+Thread #x: Exiting thread still holds 1 lock
+ ...
-ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/helgrind/tests/tc20_verifywrap.stderr.diff-glibc25-amd64
=================================================
--- tc20_verifywrap.stderr.exp-glibc25-amd64 2010-08-12 02:18:11.000000000 -0700
+++ tc20_verifywrap.stderr.out 2010-08-12 02:30:08.000000000 -0700
@@ -71,12 +71,14 @@
---------------- pthread_cond_wait et al ----------------
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
Thread #x's call to pthread_cond_wait failed
with error code 1 (EPERM: Operation not permitted)
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
@@ -86,12 +88,14 @@
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
Thread #x's call to pthread_cond_timedwait failed
with error code 22 (EINVAL: Invalid argument)
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
@@ -142,6 +146,12 @@
by 0x........: sem_wait (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:242)
+Thread #x's call to sem_post failed
+ with error code 22 (EINVAL: Invalid argument)
+ at 0x........: sem_post_WRK (hg_intercepts.c:...)
+ by 0x........: sem_post (hg_intercepts.c:...)
+ by 0x........: main (tc20_verifywrap.c:245)
+
FIXME: can't figure out how to verify wrap of sem_post
@@ -152,4 +162,4 @@
...
-ERROR SUMMARY: 20 errors from 20 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/helgrind/tests/tc20_verifywrap.stderr.diff-glibc27-amd64
=================================================
--- tc20_verifywrap.stderr.exp-glibc27-amd64 2010-08-12 02:18:11.000000000 -0700
+++ tc20_verifywrap.stderr.out 2010-08-12 02:30:08.000000000 -0700
@@ -71,12 +71,14 @@
---------------- pthread_cond_wait et al ----------------
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
Thread #x's call to pthread_cond_wait failed
with error code 1 (EPERM: Operation not permitted)
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
@@ -86,12 +88,14 @@
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
Thread #x's call to pthread_cond_timedwait failed
with error code 22 (EINVAL: Invalid argument)
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
=================================================
./valgrind-new/helgrind/tests/tc23_bogus_condwait.stderr.diff
=================================================
--- tc23_bogus_condwait.stderr.exp 2010-08-12 02:18:11.000000000 -0700
+++ tc23_bogus_condwait.stderr.out 2010-08-12 02:30:19.000000000 -0700
@@ -2,31 +2,38 @@
Thread #x is the program's root thread
Thread #x: pthread_cond_{timed}wait called with invalid mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:69)
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:72)
Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:72)
Thread #x: pthread_cond_{timed}wait called with mutex of type pthread_rwlock_t*
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:75)
Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:75)
Thread #x: pthread_cond_{timed}wait called with mutex held by a different thread
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:78)
Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:78)
=================================================
./valgrind-new/memcheck/tests/linux/stack_switch.stderr.diff
=================================================
--- stack_switch.stderr.exp 2010-08-12 02:18:35.000000000 -0700
+++ stack_switch.stderr.out 2010-08-12 02:25:15.000000000 -0700
@@ -0,0 +1,3 @@
+Syscall param clone(child_tidptr) contains uninitialised byte(s)
+ ...
+
=================================================
./valgrind-new/memcheck/tests/long_namespace_xml.stderr.diff
=================================================
--- long_namespace_xml.stderr.exp 2010-08-12 02:18:39.000000000 -0700
+++ long_namespace_xml.stderr.out 2010-08-12 02:25:24.000000000 -0700
@@ -37,7 +37,7 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm</fn>
+ <fn>_ZN53044basic_iostreamIwSt11char_traitsIwEE</fn>
<dir>...</dir>
<file>long_namespace_xml.cpp</file>
<line>...</line>
@@ -64,7 +64,7 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm</fn>
+ <fn>_ZN53044basic_iostreamIwSt11char_traitsIwEE</fn>
<dir>...</dir>
<file>long_namespace_xml.cpp</file>
<line>...</line>
=================================================
./valgrind-new/none/tests/amd64/bug132918.stdout.diff
=================================================
--- bug132918.stdout.exp 2010-08-12 02:18:59.000000000 -0700
+++ bug132918.stdout.out 2010-08-12 02:27:39.000000000 -0700
@@ -1,6 +1,6 @@
xx1 -> 0x4200 8.300000
xx2 -> 0x0000 1.440000
-xx -> 0x0000 -nan
+xx -> 0x0000 nan
xx -> 0x0000 0.809017
xx -> 0x0000 0.309018
xx -> 0x0000 -0.309015
=================================================
./valgrind-new/none/tests/amd64/fxtract.stdout.diff
=================================================
--- fxtract.stdout.exp 2010-08-12 02:18:59.000000000 -0700
+++ fxtract.stdout.out 2010-08-12 02:27:40.000000000 -0700
@@ -40,7 +40,7 @@
2.7049662808e+02 -> 1.0566274534 8.0000000000
0.0000000000e+00 -> 0.0000000000 -inf
inf -> inf inf
- -nan -> -nan -nan
+ nan -> nan nan
7.2124891681e-308 -> 1.6207302828 -1021.0000000000
5.7982756057e-308 -> 1.3029400313 -1021.0000000000
4.3840620434e-308 -> 1.9702995595 -1022.0000000000
=================================================
./valgrind-new/none/tests/x86/fxtract.stdout.diff
=================================================
--- fxtract.stdout.exp 2010-08-12 02:19:08.000000000 -0700
+++ fxtract.stdout.out 2010-08-12 02:28:47.000000000 -0700
@@ -40,7 +40,7 @@
2.7049662808e+02 -> 1.0566274534 8.0000000000
0.0000000000e+00 -> 0.0000000000 -inf
inf -> inf inf
- -nan -> -nan -nan
+ nan -> nan nan
7.2124891681e-308 -> 1.6207302828 -1021.0000000000
5.7982756057e-308 -> 1.3029400313 -1021.0000000000
4.3840620434e-308 -> 1.9702995595 -1022.0000000000
=================================================
./valgrind-old/exp-ptrcheck/tests/bad_percentify.stderr.diff-glibc28-amd64
=================================================
--- bad_percentify.stderr.exp-glibc28-amd64 2010-08-12 02:00:48.000000000 -0700
+++ bad_percentify.stderr.out 2010-08-12 02:16:39.000000000 -0700
@@ -1,32 +1,29 @@
Invalid read of size 1
- at 0x........: strlen (h_intercepts.c:...)
- by 0x........: ...
+ at 0x........: ...
by 0x........: ...
by 0x........: VG_print_translation_stats (bad_percentify.c:88)
by 0x........: main (bad_percentify.c:107)
Address 0x........ expected vs actual:
- Expected: stack array "buf" in frame 3 back from here
+ Expected: stack array "buf" in frame 2 back from here
Actual: unknown
Invalid read of size 1
- at 0x........: strlen (h_intercepts.c:...)
- by 0x........: ...
+ at 0x........: ...
by 0x........: ...
by 0x........: VG_print_translation_stats (bad_percentify.c:93)
by 0x........: main (bad_percentify.c:107)
Address 0x........ expected vs actual:
- Expected: stack array "buf" in frame 3 back from here
+ Expected: stack array "buf" in frame 2 back from here
Actual: unknown
Invalid read of size 1
- at 0x........: strlen (h_intercepts.c:...)
- by 0x........: ...
+ at 0x........: ...
by 0x........: ...
by 0x........: VG_print_translation_stats (bad_percentify.c:98)
by 0x........: main (bad_percentify.c:107)
Address 0x........ expected vs actual:
- Expected: stack array "buf" in frame 3 back from here
+ Expected: stack array "buf" in frame 2 back from here
Actual: unknown
=================================================
./valgrind-old/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2010-08-12 02:00:43.000000000 -0700
+++ tc06_two_races_xml.stderr.out 2010-08-12 02:12:13.000000000 -0700
@@ -40,16 +40,25 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
+ <fn>T.102</fn>
+ <dir>...</dir>
+ <file>createthread.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>pthread_create@@GLIBC_2.2.5</fn>
+ <dir>...</dir>
+ <file>createthread.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
@@ -121,11 +130,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat>
@@ -175,11 +190,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat>
@@ -229,11 +250,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot2"</auxwhat>
@@ -283,11 +310,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
<fn>clone</fn>
+ <dir>...</dir>
+ <file>clone.S</file>
+ <line>...</line>
</frame>
</stack>
<truncated beyond 100 lines>
=================================================
./valgrind-old/helgrind/tests/tc09_bad_unlock.stderr.diff-glibc23-amd64
=================================================
--- tc09_bad_unlock.stderr.exp-glibc23-amd64 2010-08-12 02:00:43.000000000 -0700
+++ tc09_bad_unlock.stderr.out 2010-08-12 02:12:16.000000000 -0700
@@ -31,14 +31,13 @@
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:49)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:49)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
+Thread #x's call to pthread_mutex_unlock failed
+ with error code 22 (EINVAL: Invalid argument)
+ at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:49)
+---------------------
Thread #x unlocked a not-locked lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:27)
@@ -46,6 +45,20 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:23)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Attempt to re-lock a non-recursive lock I already hold
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:50)
+ Lock was previously acquired
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
by 0x........: main (tc09_bad_unlock.c:50)
Thread #x was created
@@ -62,20 +75,21 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:50)
+ by 0x........: main (tc09_bad_unlock.c:49)
Thread #x unlocked an invalid lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:50)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:50)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
+Thread #x's call to pthread_mutex_unlock failed
+ with error code 22 (EINVAL: Invalid argument)
+ at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:50)
+Thread #x: Exiting thread still holds 1 lock
+ ...
+
-ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 0 from 0)
=================================================
./valgrind-old/helgrind/tests/tc09_bad_unlock.stderr.diff-glibc25-amd64
=================================================
--- tc09_bad_unlock.stderr.exp-glibc25-amd64 2010-08-12 02:00:43.000000000 -0700
+++ tc09_bad_unlock.stderr.out 2010-08-12 02:12:16.000000000 -0700
@@ -51,6 +51,10 @@
at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:32)
by 0x........: main (tc09_bad_unlock.c:50)
+ Lock was previously acquired
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:49)
Thread #x: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
=================================================
./valgrind-old/helgrind/tests/tc09_bad_unlock.stderr.diff-glibc25-x86
=================================================
--- tc09_bad_unlock.stderr.exp-glibc25-x86 2010-08-12 02:00:43.000000000 -0700
+++ tc09_bad_unlock.stderr.out 2010-08-12 02:12:16.000000000 -0700
@@ -37,14 +37,7 @@
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:49)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:49)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:49)
-
+---------------------
Thread #x unlocked a not-locked lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:27)
@@ -52,6 +45,20 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:23)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Attempt to re-lock a non-recursive lock I already hold
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:50)
+ Lock was previously acquired
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
+ by 0x........: main (tc09_bad_unlock.c:49)
+
+Thread #x: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
+ at 0x........: pthread_mutex_lock (hg_intercepts.c:...)
+ by 0x........: nearly_main (tc09_bad_unlock.c:32)
by 0x........: main (tc09_bad_unlock.c:50)
Thread #x was created
@@ -68,7 +75,7 @@
Lock at 0x........ was first observed
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:50)
+ by 0x........: main (tc09_bad_unlock.c:49)
Thread #x unlocked an invalid lock at 0x........
at 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
@@ -81,13 +88,8 @@
by 0x........: nearly_main (tc09_bad_unlock.c:41)
by 0x........: main (tc09_bad_unlock.c:50)
-Thread #x deallocated location 0x........ containing a locked lock
- at 0x........: nearly_main (tc09_bad_unlock.c:45)
- by 0x........: main (tc09_bad_unlock.c:50)
- Lock at 0x........ was first observed
- at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: nearly_main (tc09_bad_unlock.c:31)
- by 0x........: main (tc09_bad_unlock.c:50)
+Thread #x: Exiting thread still holds 1 lock
+ ...
-ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 0 from 0)
=================================================
./valgrind-old/helgrind/tests/tc20_verifywrap.stderr.diff-glibc25-amd64
=================================================
--- tc20_verifywrap.stderr.exp-glibc25-amd64 2010-08-12 02:00:43.000000000 -0700
+++ tc20_verifywrap.stderr.out 2010-08-12 02:12:35.000000000 -0700
@@ -71,12 +71,14 @@
---------------- pthread_cond_wait et al ----------------
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
Thread #x's call to pthread_cond_wait failed
with error code 1 (EPERM: Operation not permitted)
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
@@ -86,12 +88,14 @@
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
Thread #x's call to pthread_cond_timedwait failed
with error code 22 (EINVAL: Invalid argument)
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
@@ -142,6 +146,12 @@
by 0x........: sem_wait (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:242)
+Thread #x's call to sem_post failed
+ with error code 22 (EINVAL: Invalid argument)
+ at 0x........: sem_post_WRK (hg_intercepts.c:...)
+ by 0x........: sem_post (hg_intercepts.c:...)
+ by 0x........: main (tc20_verifywrap.c:245)
+
FIXME: can't figure out how to verify wrap of sem_post
@@ -152,4 +162,4 @@
...
-ERROR SUMMARY: 20 errors from 20 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)
=================================================
./valgrind-old/helgrind/tests/tc20_verifywrap.stderr.diff-glibc27-amd64
=================================================
--- tc20_verifywrap.stderr.exp-glibc27-amd64 2010-08-12 02:00:43.000000000 -0700
+++ tc20_verifywrap.stderr.out 2010-08-12 02:12:35.000000000 -0700
@@ -71,12 +71,14 @@
---------------- pthread_cond_wait et al ----------------
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
Thread #x's call to pthread_cond_wait failed
with error code 1 (EPERM: Operation not permitted)
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:147)
@@ -86,12 +88,14 @@
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
Thread #x's call to pthread_cond_timedwait failed
with error code 22 (EINVAL: Invalid argument)
- at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
by 0x........: main (tc20_verifywrap.c:165)
=================================================
./valgrind-old/helgrind/tests/tc23_bogus_condwait.stderr.diff
=================================================
--- tc23_bogus_condwait.stderr.exp 2010-08-12 02:00:43.000000000 -0700
+++ tc23_bogus_condwait.stderr.out 2010-08-12 02:12:46.000000000 -0700
@@ -2,31 +2,38 @@
Thread #x is the program's root thread
Thread #x: pthread_cond_{timed}wait called with invalid mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:69)
Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:72)
Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:72)
Thread #x: pthread_cond_{timed}wait called with mutex of type pthread_rwlock_t*
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:75)
Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:75)
Thread #x: pthread_cond_{timed}wait called with mutex held by a different thread
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:78)
Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:78)
=================================================
./valgrind-old/memcheck/tests/linux/stack_switch.stderr.diff
=================================================
--- stack_switch.stderr.exp 2010-08-12 02:01:10.000000000 -0700
+++ stack_switch.stderr.out 2010-08-12 02:07:47.000000000 -0700
@@ -0,0 +1,3 @@
+Syscall param clone(child_tidptr) contains uninitialised byte(s)
+ ...
+
=================================================
./valgrind-old/memcheck/tests/long_namespace_xml.stderr.diff
=================================================
--- long_namespace_xml.stderr.exp 2010-08-12 02:01:14.000000000 -0700
+++ long_namespace_xml.stderr.out 2010-08-12 02:07:56.000000000 -0700
@@ -37,7 +37,7 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm</fn>
+ <fn>_ZN53044basic_iostreamIwSt11char_traitsIwEE</fn>
<dir>...</dir>
<file>long_namespace_xml.cpp</file>
<line>...</line>
@@ -64,7 +64,7 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm</fn>
+ <fn>_ZN53044basic_iostreamIwSt11char_traitsIwEE</fn>
<dir>...</dir>
<file>long_namespace_xml.cpp</file>
<line>...</line>
=================================================
./valgrind-old/none/tests/amd64/bug132918.stdout.diff
=================================================
--- bug132918.stdout.exp 2010-08-12 02:01:34.000000000 -0700
+++ bug132918.stdout.out 2010-08-12 02:10:08.000000000 -0700
@@ -1,6 +1,6 @@
xx1 -> 0x4200 8.300000
xx2 -> 0x0000 1.440000
-xx -> 0x0000 -nan
+xx -> 0x0000 nan
xx -> 0x0000 0.809017
xx -> 0x0000 0.309018
xx -> 0x0000 -0.309015
=================================================
./valgrind-old/none/tests/amd64/fxtract.stdout.diff
=================================================
--- fxtract.stdout.exp 2010-08-12 02:01:34.000000000 -0700
+++ fxtract.stdout.out 2010-08-12 02:10:10.000000000 -0700
@@ -40,7 +40,7 @@
2.7049662808e+02 -> 1.0566274534 8.0000000000
0.0000000000e+00 -> 0.0000000000 -inf
inf -> inf inf
- -nan -> -nan -nan
+ nan -> nan nan
7.2124891681e-308 -> 1.6207302828 -1021.0000000000
5.7982756057e-308 -> 1.3029400313 -1021.0000000000
4.3840620434e-308 -> 1.9702995595 -1022.0000000000
=================================================
./valgrind-old/none/tests/x86/fxtract.stdout.diff
=================================================
--- fxtract.stdout.exp 2010-08-12 02:01:44.000000000 -0700
+++ fxtract.stdout.out 2010-08-12 02:11:19.000000000 -0700
@@ -40,7 +40,7 @@
2.7049662808e+02 -> 1.0566274534 8.0000000000
0.0000000000e+00 -> 0.0000000000 -inf
inf -> inf inf
- -nan -> -nan -nan
+ nan -> nan nan
7.2124891681e-308 -> 1.6207302828 -1021.0000000000
5.7982756057e-308 -> 1.3029400313 -1021.0000000000
4.3840620434e-308 -> 1.9702995595 -1022.0000000000
|
|
From: Julian S. <js...@ac...> - 2010-08-12 08:59:53
|
> > Does anyone have any insight about this?
Not me. Do you have a potential patch? Is this being tracked on the
bug tracker?
J
On Monday, August 09, 2010, Alexander Potapenko wrote:
> Found this in coregrind/m_syswrap/syswrap-darwin.c:
> =======================================
> PRE(chmod_extended)
> {
> /* DDD: Note: this is not really correct. Handling of
> fchmod_extended is broken in the same way. */
> PRINT("chmod_extended ( %#lx(%s), %ld, %ld, %ld, %#lx )",
> ARG1, ARG1 ? (HChar*)ARG1 : "(null)", ARG2, ARG3, ARG4, ARG5);
> PRE_REG_READ5(long, "chmod",
> unsigned int, fildes,
> uid_t, uid,
> gid_t, gid,
> vki_mode_t, mode,
> void* /*really,user_addr_t*/, xsecurity);
> PRE_MEM_RASCIIZ("chmod_extended(path)", ARG1);
> /* DDD: relative to the xnu sources (kauth_copyinfilesec), this
> is just way wrong. [The trouble is with the size, which depends on a
> non-trival kernel computation] */
> PRE_MEM_READ( "chmod_extended(xsecurity)", ARG5,
> sizeof(struct vki_kauth_filesec) );
> }
> =======================================
>
> As I understand, the size of the last argument of [f]chmod_extended
> may vary on 10.5. Is it still so on 10.6?
>
> On Mon, Aug 9, 2010 at 4:13 PM, Alexander Potapenko <gl...@go...>
wrote:
> > Hi all,
> >
> > I'm getting the following reports while running some Chromium
> > unittests under Memcheck on OS X 10.6:
> >
> > ===================================
> > Syscall param fchmod_extended(xsecurity) points to unaddressable byte(s)
> > __fchmod_extended
> > fchmodx_np
> > copyfile_internal
> > copyfile
> > file_util::CopyFile(FilePath const&, FilePath const&)
> > (/Users/glider/src/chromium/src/base/file_util_mac.mm:30)
> >
> > Syscall param chmod_extended(xsecurity) points to unaddressable byte(s)
> > __chmod_extended
> > chmodx_np
> > copyfile
> > file_util::CopyFile(FilePath const&, FilePath const&)
> > (/Users/glider/src/chromium/src/base/file_util_mac.mm:30)
> > ===================================
> >
> > When I run dtruss on these tests I find out that the syscalls are
> > invoked with almost no arguments:
> > chmod_extended(0x1330000, 0x0, 0x0, 0x0, 0x0) and
> > fchmod_extended(0x5, 0x0, 0x0, 0x0, 0x0)
> > , where 0x5 is a valid file descriptor (it's used by other syscalls)
> > and 0x1330000 is a valid string (ditto).
> >
> > I suspect the reports are caused by some harmless optimization which
> > was not used in 10.5 but appeared in 10.6.
> > Does anyone have any insight about this?
> >
> > Thanks in advance,
> > Alexander Potapenko
> > Software Engineer
> > Google Moscow
|
|
From: Julian S. <js...@ac...> - 2010-08-12 08:46:27
|
ARMv7 is the baseline requirement, and realistically I don't think v5 is likely to be supported. It won't work as-is. > Program terminated with signal 11, Segmentation fault. > [New process 1071] > #0 read_leb128 (data=0x403e074 <Address 0x403e074 out of bounds>, > length_return=0x388bb5cc, sign=1413) at m_debuginfo/readdwarf.c:221 > 221 byte = * data ++; That said, it looks like your build segfaulted while reading Dwarf3 debug info. Which has nothing to do with the v5 vs v7 question. Not sure why. Which compiler produced the executable/shared object that it was examining at the time? Running Valgrind with -v will tell you that. J |
|
From: Julian S. <js...@ac...> - 2010-08-12 08:41:30
|
Maynard, thanks for the patch. Please could you open a bug report and attach the patches, including the test programs, to the bug report. Patches sent to the mailing list are at (serious) risk of falling through the cracks and disappearing. Also, putting patches in the bug tracker gives a single URL at which we can point anybody interested. See http://www.valgrind.org/support/bug_reports.html for directions on filing bug reports. J On Wednesday, August 11, 2010, Maynard Johnson wrote: > On 08/11/2010 10:38 AM, Maynard Johnson wrote: > > On 08/10/2010 2:36 PM, Maynard Johnson wrote: > >> Bart Van Assche wrote: > >>> On Tue, Aug 10, 2010 at 5:59 PM, Maynard Johnson<may...@us...> wrote: > >>>> Bart Van Assche wrote: > >>>>> On Mon, Aug 9, 2010 at 11:59 PM, Maynard Johnson<may...@us...>wrote: > >>>>>> Currently, Valgrind has only partial support for new IBM POWER6 > >>>>>> instructions (as defined in > >>>>>> http://www.power.org/resources/reading/PowerISA_V2.05.pdf). The > >>>>>> attached patch completes the 2.05 support. > >>>>>> > >>>>>> The results of running 'make regtest' on a POWER6 box are almost > >>>>>> identical before and after applying this patch -- about 50 failing > >>>>>> testcases. I have looked into many of those failing testcases and, > >>>>>> so far, have been able to cut the number of failures to less than > >>>>>> half that. I have a separate testsuite patch that I will submit > >>>>>> separately (upon request, or I'll wait until this patch is > >>>>>> accepted) that provides the improved testsuite results. > >>>>>> > >>>>>> Review comments are welcome. > > > > The attached "version 2" patch fixes the formatting issues that Bart > > pointed out, plus a couple other minor nits I found while scrubbing it. > > This patch was made against a snapshot of today's SVN repository. But as > > I mentioned earlier to Bart, applying the patch will result in an > > expected failure involving none/tests/ppc64/jm-insns.c, since this file > > is symbolically linked to none/tests/ppc32/jm-insns.c, which is patched > > earlier on during the patch application. Just hit "Enter" twice to > > ignore that failure, and the rest of the patch should apply cleanly. > > Another thing I should have mentioned . . . This patch contains some new > shell scripts which need to be changed to executable before attempting to > run the testsuite. These new script files are: > - memcheck/tests/ppc32/filter_stderr > - memcheck/tests/ppc64/filter_stderr > - none/tests/ppc32/check_vmx_cap > - none/tests/ppc64/check_vmx_cap > > -Maynard > > > Thanks. > > -Maynard > > > > > > > > ------------------------------------------------------------------------- > > ----- This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > > > > > > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > --------------------------------------------------------------------------- > --- This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <sv...@va...> - 2010-08-12 07:48:36
|
Author: sewardj
Date: 2010-08-12 08:48:27 +0100 (Thu, 12 Aug 2010)
New Revision: 11256
Log:
Ubuntu 10.04/ARM fixes:
- support sys_pselect6
- make a couple of redirs mandatory
- add a ld.so supp
Modified:
branches/THUMB/Makefile.all.am
branches/THUMB/coregrind/m_redir.c
branches/THUMB/coregrind/m_syswrap/syswrap-arm-linux.c
branches/THUMB/glibc-2.X.supp.in
branches/THUMB/include/vki/vki-scnums-arm-linux.h
Modified: branches/THUMB/Makefile.all.am
===================================================================
--- branches/THUMB/Makefile.all.am 2010-08-10 08:05:40 UTC (rev 11255)
+++ branches/THUMB/Makefile.all.am 2010-08-12 07:48:27 UTC (rev 11256)
@@ -91,7 +91,7 @@
@FLAG_W_NO_FORMAT_ZERO_LENGTH@ \
-fno-strict-aliasing \
\
- -O0
+ -O
# These flags are used for building the preload shared objects.
# The aim is to give reasonable performance but also to have good
Modified: branches/THUMB/coregrind/m_redir.c
===================================================================
--- branches/THUMB/coregrind/m_redir.c 2010-08-10 08:05:40 UTC (rev 11255)
+++ branches/THUMB/coregrind/m_redir.c 2010-08-12 07:48:27 UTC (rev 11256)
@@ -1009,7 +1009,7 @@
add_hardwired_spec(
"ld-linux.so.3", "strlen",
(Addr)&VG_(arm_linux_REDIR_FOR_strlen),
- NULL
+ complain_about_stripped_glibc_ldso
);
//add_hardwired_spec(
// "ld-linux.so.3", "index",
@@ -1019,7 +1019,7 @@
add_hardwired_spec(
"ld-linux.so.3", "memcpy",
(Addr)&VG_(arm_linux_REDIR_FOR_memcpy),
- NULL
+ complain_about_stripped_glibc_ldso
);
}
/* nothing so far */
Modified: branches/THUMB/coregrind/m_syswrap/syswrap-arm-linux.c
===================================================================
--- branches/THUMB/coregrind/m_syswrap/syswrap-arm-linux.c 2010-08-10 08:05:40 UTC (rev 11255)
+++ branches/THUMB/coregrind/m_syswrap/syswrap-arm-linux.c 2010-08-12 07:48:27 UTC (rev 11256)
@@ -1657,6 +1657,8 @@
// correspond to what's in include/vki/vki-scnums-arm-linux.h.
// From here onwards, please ensure the numbers are correct.
+ LINX_(__NR_pselect6, sys_pselect6), // 335
+
LINXY(__NR_signalfd4, sys_signalfd4), // 355
LINX_(__NR_eventfd2, sys_eventfd2), // 356
Modified: branches/THUMB/glibc-2.X.supp.in
===================================================================
--- branches/THUMB/glibc-2.X.supp.in 2010-08-10 08:05:40 UTC (rev 11255)
+++ branches/THUMB/glibc-2.X.supp.in 2010-08-12 07:48:27 UTC (rev 11256)
@@ -228,3 +228,11 @@
obj:/lib/libpthread-0.10.so
fun:pthread_create
}
+
+##----------------------------------------------------------------------##
+# Ubuntu 10.04 on ARM (Thumb). Not sure why this is necessary.
+{
+ U1004-ARM-_dl_relocate_object
+ Memcheck:Cond
+ fun:_dl_relocate_object
+}
Modified: branches/THUMB/include/vki/vki-scnums-arm-linux.h
===================================================================
--- branches/THUMB/include/vki/vki-scnums-arm-linux.h 2010-08-10 08:05:40 UTC (rev 11255)
+++ branches/THUMB/include/vki/vki-scnums-arm-linux.h 2010-08-12 07:48:27 UTC (rev 11256)
@@ -370,7 +370,7 @@
#define __NR_readlinkat 332
#define __NR_fchmodat 333
#define __NR_faccessat 334
- /* 335 for pselect6 */
+#define __NR_pselect6 335 /* JRS 20100812: is this correct? */
/* 336 for ppoll */
#define __NR_unshare 337
#define __NR_set_robust_list 338
|
|
From: <sv...@va...> - 2010-08-12 07:40:36
|
Author: sewardj
Date: 2010-08-12 08:40:27 +0100 (Thu, 12 Aug 2010)
New Revision: 2007
Log:
Thumb fixes:
- mark guest_ITSTATE as always defined
- spot "Special" instructions in Thumb mode
- improve IT-avoidance analyser
- add in-line test for Thumb insns gated on AL, so Memcheck
understands they don't depend on the flags thunk
- fix incorrect handling of ADC.W/SBC.W reg,reg,shift
- handle TEQ.W reg,reg,shift, UMLAL, SMLAL, MSR, MRS
- stores that update basereg: do update before the store
- loads that load R15: don't assert
Modified:
branches/THUMB/priv/guest_arm_helpers.c
branches/THUMB/priv/guest_arm_toIR.c
Modified: branches/THUMB/priv/guest_arm_helpers.c
===================================================================
--- branches/THUMB/priv/guest_arm_helpers.c 2010-08-09 08:57:27 UTC (rev 2006)
+++ branches/THUMB/priv/guest_arm_helpers.c 2010-08-12 07:40:27 UTC (rev 2007)
@@ -649,7 +649,7 @@
/* Describe any sections to be regarded by Memcheck as
'always-defined'. */
- .n_alwaysDefd = 9,
+ .n_alwaysDefd = 10,
/* flags thunk: OP is always defd, whereas DEP1 and DEP2
have to be tracked. See detailed comment in gdefs.h on
@@ -663,7 +663,8 @@
/* 5 */ ALWAYSDEFD(guest_TILEN),
/* 6 */ ALWAYSDEFD(guest_NRADDR),
/* 7 */ ALWAYSDEFD(guest_IP_AT_SYSCALL),
- /* 8 */ ALWAYSDEFD(guest_TPIDRURO)
+ /* 8 */ ALWAYSDEFD(guest_TPIDRURO),
+ /* 9 */ ALWAYSDEFD(guest_ITSTATE)
}
};
Modified: branches/THUMB/priv/guest_arm_toIR.c
===================================================================
--- branches/THUMB/priv/guest_arm_toIR.c 2010-08-09 08:57:27 UTC (rev 2006)
+++ branches/THUMB/priv/guest_arm_toIR.c 2010-08-12 07:40:27 UTC (rev 2007)
@@ -54,6 +54,12 @@
are moderately often needed in Thumb code.
Correctness: ITSTATE handling in Thumb SVCs is wrong.
+
+ Correctness (obscure): in m_transtab, when invalidating code
+ address ranges, invalidate up to 18 bytes after the end of the
+ range. This is because the ITSTATE optimisation at the top of
+ _THUMB_WRK below analyses up to 18 bytes before the start of any
+ given instruction, and so might depend on the invalidated area.
*/
/* Limitations, etc
@@ -63,7 +69,6 @@
- SWP: the restart jump back is Ijk_Boring; it should be
Ijk_NoRedir but that's expensive. See comments on casLE() in
guest_x86_toIR.c.
-
*/
/* "Special" instructions.
@@ -2308,6 +2313,9 @@
vassert(mask <= 0xF);
*itstate = 0;
*ch1 = *ch2 = *ch3 = '.';
+ if (mask == 0)
+ return False; /* the logic below actually ensures this anyway,
+ but clearer to make it explicit. */
if (firstcond == 0xF)
return False; /* NV is not allowed */
if (firstcond == 0xE && popcount32(mask) != 1)
@@ -9775,6 +9783,7 @@
case BITS4(0,1,1,1): /* RSC: Rd = shifter_operand - Rn - (oldC ^ 1) */
name = "rsc"; goto rd_eq_rn_op_SO_op_oldC;
rd_eq_rn_op_SO_op_oldC: {
+ // FIXME: shco isn't used for anything. Get rid of it.
rNt = newTemp(Ity_I32);
assign(rNt, getIRegA(rN));
ok = mk_shifter_operand(
@@ -11552,36 +11561,38 @@
}
/* ----------------------------------------------------------- */
-#if 0
/* Spot "Special" instructions (see comment at top of file). */
{
UChar* code = (UChar*)guest_instr;
/* Spot the 16-byte preamble:
- e1a0c1ec mov r12, r12, ROR #3
- e1a0c6ec mov r12, r12, ROR #13
- e1a0ceec mov r12, r12, ROR #29
- e1a0c9ec mov r12, r12, ROR #19
+ ea4f 0cfc mov.w ip, ip, ror #3
+ ea4f 3c7c mov.w ip, ip, ror #13
+ ea4f 7c7c mov.w ip, ip, ror #29
+ ea4f 4cfc mov.w ip, ip, ror #19
*/
- UInt word1 = 0xE1A0C1EC;
- UInt word2 = 0xE1A0C6EC;
- UInt word3 = 0xE1A0CEEC;
- UInt word4 = 0xE1A0C9EC;
+ UInt word1 = 0x0CFCEA4F;
+ UInt word2 = 0x3C7CEA4F;
+ UInt word3 = 0x7C7CEA4F;
+ UInt word4 = 0x4CFCEA4F;
if (getUIntLittleEndianly(code+ 0) == word1 &&
getUIntLittleEndianly(code+ 4) == word2 &&
getUIntLittleEndianly(code+ 8) == word3 &&
getUIntLittleEndianly(code+12) == word4) {
/* Got a "Special" instruction preamble. Which one is it? */
- if (getUIntLittleEndianly(code+16) == 0xE18AA00A
- /* orr r10,r10,r10 */) {
+ // 0x 0A 0A EA 4A
+ if (getUIntLittleEndianly(code+16) == 0x0A0AEA4A
+ /* orr.w r10,r10,r10 */) {
/* R3 = client_request ( R4 ) */
DIP("r3 = client_request ( %%r4 )\n");
- irsb->next = mkU32( guest_R15_curr_instr_notENC + 20 );
+ irsb->next = mkU32( (guest_R15_curr_instr_notENC + 20) | 1 );
irsb->jumpkind = Ijk_ClientReq;
dres.whatNext = Dis_StopHere;
goto decode_success;
}
+#if 0
else
+ // 0x 0B 0B EA 4B
if (getUIntLittleEndianly(code+16) == 0xE18BB00B
/* orr r11,r11,r11 */) {
/* R3 = guest_NRADDR */
@@ -11591,6 +11602,7 @@
goto decode_success;
}
else
+ // 0x 0C 0C EA 4C
if (getUIntLittleEndianly(code+16) == 0xE18CC00C
/* orr r12,r12,r12 */) {
/* branch-and-link-to-noredir R4 */
@@ -11601,15 +11613,16 @@
dres.whatNext = Dis_StopHere;
goto decode_success;
}
- /* We don't know what it is. Set opc1/opc2 so decode_failure
+#endif
+ /* We don't know what it is. Set insn0 so decode_failure
can print the insn following the Special-insn preamble. */
- insn = getUIntLittleEndianly(code+16);
+ insn0 = getUShortLittleEndianly(code+16);
goto decode_failure;
/*NOTREACHED*/
}
}
-#endif
+
/* ----------------------------------------------------------- */
/* Main Thumb instruction decoder starts here. It's a series of
@@ -11676,7 +11689,9 @@
vassert( ( ((UInt)(&hwp[i])) & 0xFFFFF000 )
== ( pc & 0xFFFFF000 ) );
*/
- if ((hwp[i] & 0xFF00) == 0xBF00) {
+ /* All valid IT instructions must have the form 0xBFxy,
+ where x can be anything, but y must be nonzero. */
+ if ((hwp[i] & 0xFF00) == 0xBF00 && (hwp[i] & 0xF) != 0) {
/* might be an 'it' insn. Play safe. */
forceZ = False;
break;
@@ -11714,8 +11729,8 @@
to decide whether they can generate straight-line code, or
whether they must generate a side exit before the instruction.
condT :: Ity_I32 and is always either zero or one. */
- IRTemp condT = newTemp(Ity_I32);
- assign(condT,
+ IRTemp condT1 = newTemp(Ity_I32);
+ assign(condT1,
mk_armg_calculate_condition_dyn(
binop(Iop_Xor32,
binop(Iop_And32, mkexpr(old_itstate), mkU32(0xF0)),
@@ -11723,6 +11738,35 @@
)
);
+ /* This is a bit complex, but needed to make Memcheck understand
+ that, if the condition in old_itstate[7:4] denotes AL (that is,
+ if this instruction is to be executed unconditionally), then
+ condT does not depend on the results of calling the helper.
+
+ We test explicitly for old_itstate[7:4] == AL ^ 0xE, and in that
+ case set condT directly to 1. Else we use the results of the
+ helper. Since old_itstate is always defined and because
+ Memcheck does lazy V-bit propagation through Mux0X, this will
+ cause condT to always be a defined 1 if the condition is 'AL'.
+ From an execution semantics point of view this is irrelevant
+ since we're merely duplicating part of the behaviour of the
+ helper. But it makes it clear to Memcheck, in this case, that
+ condT does not in fact depend on the contents of the condition
+ code thunk. Without it, we get quite a lot of false errors.
+
+ So, just to clarify: from a straight semantics point of view, we
+ can simply do "assign(condT, mkexpr(condT1))", and the simulator
+ still runs fine. It's just that we get loads of false errors
+ from Memcheck. */
+ IRTemp condT = newTemp(Ity_I32);
+ assign(condT, IRExpr_Mux0X(
+ unop(Iop_32to8, binop(Iop_And32,
+ mkexpr(old_itstate),
+ mkU32(0xF0))),
+ mkU32(1),
+ mkexpr(condT1)
+ ));
+
/* Something we don't have in ARM: generate a 0 or 1 value
indicating whether or not we are in an IT block (NB: 0 = in IT
block, 1 = not in IT block). This is used to gate condition
@@ -13506,10 +13550,12 @@
IRTemp rMt = newTemp(Ity_I32);
assign(rMt, getIRegT(rM));
+ IRTemp oldC = newTemp(Ity_I32);
+ assign(oldC, mk_armg_calculate_flag_c());
+
IRTemp argR = newTemp(Ity_I32);
- IRTemp oldC = newTemp(Ity_I32);
compute_result_and_C_after_shift_by_imm5(
- dis_buf, &argR, &oldC, rMt, how, imm5, rM
+ dis_buf, &argR, NULL, rMt, how, imm5, rM
);
HChar* nm = "???";
@@ -13532,6 +13578,7 @@
binop(Iop_Sub32,
binop(Iop_Sub32, mkexpr(argL), mkexpr(argR)),
binop(Iop_Xor32, mkexpr(oldC), mkU32(1)) ));
+ putIRegT(rD, mkexpr(res), condT);
if (bS)
setFlags_D1_D2_ND( ARMG_CC_OP_SBB,
argL, argR, oldC, condT );
@@ -13690,14 +13737,17 @@
}
/* -------------- (T?) TST.W Rn, Rm, {shift} -------------- */
- // Ditto TEQ
+ /* -------------- (T?) TEQ.W Rn, Rm, {shift} -------------- */
if (INSN0(15,9) == BITS7(1,1,1,0,1,0,1)
- && INSN0(8,4) == BITS5(0,0,0,0,1) // TEQ: 01001
+ && ( INSN0(8,4) == BITS5(0,0,0,0,1) // TST
+ || INSN0(8,4) == BITS5(0,1,0,0,1)) // TEQ
&& INSN1(15,15) == 0
&& INSN1(11,8) == BITS4(1,1,1,1)) {
UInt rN = INSN0(3,0);
UInt rM = INSN1(3,0);
if (!isBadRegT(rN) && !isBadRegT(rM)) {
+ Bool isTST = INSN0(8,4) == BITS5(0,0,0,0,1);
+
UInt how = INSN1(5,4);
UInt imm5 = (INSN1(14,12) << 2) | INSN1(7,6);
@@ -13717,11 +13767,12 @@
assign( oldV, mk_armg_calculate_flag_v() );
IRTemp res = newTemp(Ity_I32);
- assign(res, binop(Iop_And32, mkexpr(argL), mkexpr(argR)));
+ assign(res, binop(isTST ? Iop_And32 : Iop_Xor32,
+ mkexpr(argL), mkexpr(argR)));
setFlags_D1_D2_ND( ARMG_CC_OP_LOGIC, res, oldC, oldV,
condT );
- DIP("tst.w r%u, %s\n", rN, dis_buf);
+ DIP("%s.w r%u, %s\n", isTST ? "tst" : "teq", rN, dis_buf);
goto decode_success;
}
}
@@ -13906,8 +13957,28 @@
IRTemp transAddr = bP == 1 ? postAddr : preAddr;
if (isST) {
+
+ /* Store. If necessary, update the base register before
+ the store itself, so that the common idiom of "str rX,
+ [sp, #-4]!" (store rX at sp-4, then do new sp = sp-4,
+ a.k.a "push rX") doesn't cause Memcheck to complain
+ that the access is below the stack pointer. Also, not
+ updating sp before the store confuses Valgrind's
+ dynamic stack-extending logic. So do it before the
+ store. Hence we need to snarf the store data before
+ doing the basereg update. */
+
+ /* get hold of the data to be stored */
IRTemp oldRt = newTemp(Ity_I32);
assign(oldRt, getIRegT(rT));
+
+ /* Update Rn if necessary. */
+ if (bW == 1) {
+ vassert(rN != rT); // assured by validity check above
+ putIRegT(rN, mkexpr(postAddr), IRTemp_INVALID);
+ }
+
+ /* generate the transfer */
switch (ty) {
case Ity_I8:
storeLE(mkexpr(transAddr),
@@ -13923,7 +13994,12 @@
default:
vassert(0);
}
+
} else {
+
+ /* Load. */
+
+ /* generate the transfer */
IRTemp newRt = newTemp(Ity_I32);
IROp widen = Iop_INVALID;
switch (ty) {
@@ -13941,7 +14017,12 @@
} else {
assign(newRt, unop(widen, loadLE(ty, mkexpr(transAddr))));
}
- putIRegT(rT, mkexpr(newRt), IRTemp_INVALID);
+ if (loadsPC) {
+ vassert(rT == 15);
+ llPutIReg(rT, mkexpr(newRt));
+ } else {
+ putIRegT(rT, mkexpr(newRt), IRTemp_INVALID);
+ }
if (loadsPC) {
/* Presumably this is an interworking branch. */
@@ -13949,10 +14030,12 @@
irsb->jumpkind = Ijk_Boring; /* or _Ret ? */
dres.whatNext = Dis_StopHere;
}
- }
- if (bW == 1) {
- putIRegT(rN, mkexpr(postAddr), IRTemp_INVALID);
+ /* Update Rn if necessary. */
+ if (bW == 1) {
+ vassert(rN != rT); // assured by validity check above
+ putIRegT(rN, mkexpr(postAddr), IRTemp_INVALID);
+ }
}
if (bP == 1 && bW == 0) {
@@ -14614,6 +14697,41 @@
}
}
+ /* ----------------- (T1) UMLAL ----------------- */
+ /* ----------------- (T1) SMLAL ----------------- */
+ if ((INSN0(15,4) == 0xFBE // UMLAL
+ || INSN0(15,4) == 0xFBC) // SMLAL
+ && INSN1(7,4) == BITS4(0,0,0,0)) {
+ UInt rN = INSN0(3,0);
+ UInt rDlo = INSN1(15,12);
+ UInt rDhi = INSN1(11,8);
+ UInt rM = INSN1(3,0);
+ if (!isBadRegT(rDlo) && !isBadRegT(rDhi) && !isBadRegT(rN)
+ && !isBadRegT(rM) && rDhi != rDlo) {
+ Bool isS = INSN0(15,4) == 0xFBC;
+ IRTemp argL = newTemp(Ity_I32);
+ IRTemp argR = newTemp(Ity_I32);
+ IRTemp old = newTemp(Ity_I64);
+ IRTemp res = newTemp(Ity_I64);
+ IRTemp resHi = newTemp(Ity_I32);
+ IRTemp resLo = newTemp(Ity_I32);
+ IROp mulOp = isS ? Iop_MullS32 : Iop_MullU32;
+ assign( argL, getIRegT(rM));
+ assign( argR, getIRegT(rN));
+ assign( old, binop(Iop_32HLto64, getIRegT(rDhi), getIRegT(rDlo)) );
+ assign( res, binop(Iop_Add64,
+ mkexpr(old),
+ binop(mulOp, mkexpr(argL), mkexpr(argR))) );
+ assign( resHi, unop(Iop_64HIto32, mkexpr(res)) );
+ assign( resLo, unop(Iop_64to32, mkexpr(res)) );
+ putIRegT( rDhi, mkexpr(resHi), condT );
+ putIRegT( rDlo, mkexpr(resLo), condT );
+ DIP("%cmlal r%u, r%u, r%u, r%u\n",
+ isS ? 's' : 'u', rDlo, rDhi, rN, rM);
+ goto decode_success;
+ }
+ }
+
/* ------------------ (T2) ADR ------------------ */
if ((INSN0(15,0) == 0xF2AF || INSN0(15,0) == 0xF6AF)
&& INSN1(15,15) == 0) {
@@ -14777,6 +14895,56 @@
}
}
+ /* -------------- (T1) MSR apsr, reg -------------- */
+ if (INSN0(15,4) == 0xF38
+ && INSN1(15,12) == BITS4(1,0,0,0) && INSN1(9,0) == 0x000) {
+ UInt rN = INSN0(3,0);
+ UInt write_ge = INSN1(10,10);
+ UInt write_nzcvq = INSN1(11,11);
+ if (!isBadRegT(rN) && write_nzcvq && !write_ge) {
+ IRTemp rNt = newTemp(Ity_I32);
+ assign(rNt, getIRegT(rN));
+ // Do NZCV
+ IRTemp immT = newTemp(Ity_I32);
+ assign(immT, binop(Iop_And32, mkexpr(rNt), mkU32(0xF0000000)) );
+ setFlags_D1(ARMG_CC_OP_COPY, immT, condT);
+ // Do Q
+ IRTemp qnewT = newTemp(Ity_I32);
+ assign(qnewT, binop(Iop_And32, mkexpr(rNt), mkU32(ARMG_CC_MASK_Q)));
+ put_QFLAG32(qnewT, condT);
+ //
+ DIP("msr cpsr_f, r%u\n", rN);
+ goto decode_success;
+ }
+ }
+
+ /* -------------- (T1) MRS reg, apsr -------------- */
+ if (INSN0(15,0) == 0xF3EF
+ && INSN1(15,12) == BITS4(1,0,0,0) && INSN1(7,0) == 0x00) {
+ UInt rD = INSN1(11,8);
+ if (!isBadRegT(rD)) {
+ IRTemp res1 = newTemp(Ity_I32);
+ // Get NZCV
+ assign( res1, mk_armg_calculate_flags_nzcv() );
+ /// OR in the Q value
+ IRTemp res2 = newTemp(Ity_I32);
+ assign(
+ res2,
+ binop(Iop_Or32,
+ mkexpr(res1),
+ binop(Iop_Shl32,
+ unop(Iop_1Uto32,
+ binop(Iop_CmpNE32,
+ mkexpr(get_QFLAG32()),
+ mkU32(0))),
+ mkU8(ARMG_CC_SHIFT_Q)))
+ );
+ putIRegT( rD, mkexpr(res2), condT );
+ DIP("mrs r%u, cpsr\n", rD);
+ goto decode_success;
+ }
+ }
+
/* ----------------------------------------------------------- */
/* -- VFP (CP 10, CP 11) instructions (in Thumb mode) -- */
/* ----------------------------------------------------------- */
|