|
From: <jhr...@t-...> - 2003-08-03 13:21:14
|
Hi all, first of all thanks for giving us such a great tool. I've just upgraded from 1.0.3 to valgrind-20030725. The new valgrind is failing for one of my programs (compiled with ICC 7.1) complaining ==12750== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==12750== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==12750== Using valgrind-20030725, a program supervision framework for x86-linux. ==12750== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==12750== Estimated CPU clock rate is 1714 MHz ==12750== For more details, rerun with: -v ==12750== test_vector [snip] disInstr: unhandled instruction bytes: 0xF3 0xF 0x7E 0x44 ==12750== Use of uninitialised value of size 4 ==12750== at 0x8050E00: has_osfxsr_set (in /usr/local/lib/boost_dev/boost/libs/numeric/ublas/test1/bin/test1/intel-linu x/debug/runtime-link-dynamic/test1) ==12750== ==12750== Jump to the invalid address stated on the next line ==12750== at 0x0: ??? ==12750== Address 0x0 is not stack'd, malloc'd or free'd whereas the old one reports (for the same image) ==12334== valgrind-1.0.3, a memory error detector for x86 GNU/Linux. ==12334== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==12334== Estimated CPU clock rate is 1719 MHz ==12334== For more details, rerun with: -v ==12334== test_vector [snip] ==12334== ==12334== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==12334== malloc/free: in use at exit: 300 bytes in 21 blocks. ==12334== malloc/free: 281 allocs, 260 frees, 6272 bytes allocated. ==12334== For a detailed leak analysis, rerun with: --leak-check=yes ==12334== For counts of detected errors, rerun with: -v Is this a known problem? Thanks, Joerg |
|
From: Tom H. <th...@cy...> - 2003-08-03 13:59:19
|
In message <001801c359c0$d1a748a0$010...@ms...>
jhr...@t-... (Joerg Walter) wrote:
> I've just upgraded from 1.0.3 to valgrind-20030725. The new valgrind is
> failing for one of my programs (compiled with ICC 7.1) complaining
[ snipped]
> disInstr: unhandled instruction bytes: 0xF3 0xF 0x7E 0x44
That looks like an SSE instruction to me, presumably one that Julian
hasn't added support for yet.
Presumably your program using CPUID to check for SSE support before
trying to use SSE instructions, which would be fine in 1.0.3 where
the CPUID would not have indicated SSE support when running under
valgrind.
Because CPUID now reports SSE support if your underlying CPU has it
your code will try and se it and then fail because the valrind support
for SSE is not complete yet.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
Dnia nie 3. sierpie=F1 2003 15:58, Tom Hughes napisa=B3: > That looks like an SSE instruction to me, presumably one that Julian > hasn't added support for yet. > > Presumably your program using CPUID to check for SSE support before > trying to use SSE instructions, which would be fine in 1.0.3 where > the CPUID would not have indicated SSE support when running under > valgrind. > > Because CPUID now reports SSE support if your underlying CPU has it > your code will try and se it and then fail because the valrind support > for SSE is not complete yet. Wouldn't be that a good idea to allow for command line switch to turn on/= off=20 particular CPUID flags? This would allow not only to work around missing = SSE=20 instructions, but also allow to effectively check/debug executables with=20 variant code depending on presence of various CPU features (some performa= nce=20 oriented apps do that; also ICC above 6.0 or 7.0 does that stuff=20 automatically). rgds Sebastian |
|
From: Nicholas N. <nj...@ca...> - 2003-08-03 19:53:04
|
On Sun, 3 Aug 2003, Sebastian Kaliszewski wrote: > Wouldn't be that a good idea to allow for command line switch to turn on/off > particular CPUID flags? Er, probably. In the meantime, you can workaround it by copying the old implementation of CPUID into the new version of Valgrind and recompiling (from vg_helpers.S in 1.0.3 --> coregrind/vg_helpers.S in the latest version, IIRC). N |
|
From: <jhr...@t-...> - 2003-08-03 21:01:44
|
----- Original Message -----
From: "Nicholas Nethercote" <nj...@ca...>
To: "Sebastian Kaliszewski" <sk@z.pl>
Cc: <val...@li...>
Sent: Sunday, August 03, 2003 9:53 PM
Subject: Re: [Valgrind-users] Regression w.r.t. 1.0.3?
> On Sun, 3 Aug 2003, Sebastian Kaliszewski wrote:
>
> > Wouldn't be that a good idea to allow for command line switch to turn
on/off
> > particular CPUID flags?
>
> Er, probably.
That would be great.
> In the meantime, you can workaround it by copying the old implementation
> of CPUID into the new version of Valgrind and recompiling (from
> vg_helpers.S in 1.0.3 --> coregrind/vg_helpers.S in the latest version,
> IIRC).
Tom Hughes sent the correct patch already:
--- vg_helpers.S.orig 2003-06-23 08:10:59.000000000 +0100
+++ vg_helpers.S 2003-08-03 16:33:48.000000000 +0100
@@ -135,12 +135,20 @@
pushl %edx
movl 32(%esp), %eax
+ cmpl $1, %eax
+ je cpuid_nosse
+
cmpl $0x80000001, %eax
je cpuid_no3dnow
cpuid
jmp cpuid__99
+cpuid_nosse:
+ cpuid
+ andl $0xf9ffffff, %edx
+ jmp cpuid__99
+
cpuid_no3dnow:
cpuid
Thanks,
Joerg
|