|
From: David K. <dw...@de...> - 2006-04-29 16:48:47
Attachments:
int.stderr.exp.patch
|
Hi, The attached patch changes the expected output of none/tests/x86/int to match what valgrind emits on my system (currnet Debian unstable).=20 Based on my reading of the revision history of this test, initially added here: http://websvn.kde.org/trunk/valgrind/none/tests/x86/int.c?rev=3D356199&view= =3Dlog and the bug that caused this test to be added to the testsuite in the first place: http://bugs.kde.org/show_bug.cgi?id=3D76839 all we want valgrind to do is to emit a clear message indicating that the program has tried to execute an illegal instruction. It looks to me like valgrinds behavior in this case is now correct. -David |
|
From: Tom H. <to...@co...> - 2006-04-29 19:14:24
|
In message <2f7...@ma...>
"David Kimdon" <dw...@de...> wrote:
> The attached patch changes the expected output of none/tests/x86/int
> to match what valgrind emits on my system (currnet Debian unstable).
> Based on my reading of the revision history of this test, initially
> added here:
>
> http://websvn.kde.org/trunk/valgrind/none/tests/x86/int.c?rev=356199&view=log
>
> and the bug that caused this test to be added to the testsuite in the
> first place:
>
> http://bugs.kde.org/show_bug.cgi?id=76839
>
> all we want valgrind to do is to emit a clear message indicating that
> the program has tried to execute an illegal instruction. It looks to
> me like valgrinds behavior in this case is now correct.
Actually ideally we want valgrind to raise the same signal to the
programs that it would normally get without valgrind, and I believe
that is what the test currently expects.
The fact that valgrind currently behaves different to the OS here
is arguably a bug.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2006-04-30 02:45:58
|
On Sat, 29 Apr 2006, Tom Hughes wrote: >> The attached patch changes the expected output of none/tests/x86/int >> to match what valgrind emits on my system (currnet Debian unstable). >> Based on my reading of the revision history of this test, initially >> added here: >> >> http://websvn.kde.org/trunk/valgrind/none/tests/x86/int.c?rev=356199&view=log >> >> and the bug that caused this test to be added to the testsuite in the >> first place: >> >> http://bugs.kde.org/show_bug.cgi?id=76839 >> >> all we want valgrind to do is to emit a clear message indicating that >> the program has tried to execute an illegal instruction. It looks to >> me like valgrinds behavior in this case is now correct. > > Actually ideally we want valgrind to raise the same signal to the > programs that it would normally get without valgrind, and I believe > that is what the test currently expects. > > The fact that valgrind currently behaves different to the OS here > is arguably a bug. Yes. It worked (raised the signal) in 2.4.0, but got broken when the JIT was rewritten in 3.0.0. The 'int' instruction is used legitimately by at least one JVM for throwing exceptions. Nick |