Summary: | Opteron: vex amd64->IR: unhandled instruction bytes (prefetch) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Nicholas Jones <carpaski> |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 3.0.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Nicholas Jones
2005-08-09 19:06:28 UTC
Quick note, in case to clairify: Athlon64 (939) seems to work fine, but Opterons (940) do not. Additional bits of insight: On SMP Opterons, I see the unhandled instructions. On single-proc, non-SMP kernels, at least two of us see infinate looping that is very resistant to kill -9. Neither of the two bugs you mention seem to be in any way related - both are missing x87 instructions while the instruction that I think you are talking about is a prefetch instruction. If you do encounter an unsupported instruction then all you really need to report is the last few lines of the valgrind output that report what the unrecognised instruction was - there really is no need to write a minor essay and attach tons of gdb output and things. Can you confirm exactly what valgrind says when it fails? I think that if I'm reading what you say correctly that the unrecognised instruction bytes start with "0xF 0xD" - is that correct? If so then that is a prefetch instruction. I find it easier and quicker to be overcomplete than delay the process when I'm not conversing interactively. Sorry if it was a bit much. It's in the 3 files. The top of this one is easiest: http://www.twobit.net/~carpaski/vg3/vg3-illegal-strace.log vex amd64->IR: unhandled instruction bytes: 0xF 0xD 0x8 0xF ==20651== ==20651== Process terminating with default of signal 4 (SIGILL) ==20651== Illegal opcode at address 0x140EEDED1433 ==20651== at 0x140EEDED1433: recode_new_outer (in /usr/lib64/librecode.so.0.0.0) ==20651== by 0x4047FE: (within /usr/bin/fortune) ==20651== by 0x140EEE10ACFF: __libc_start_main (in /lib64/libc-2.3.5.so) ==20651== by 0x4018B9: (within /usr/bin/fortune) Yep. That's a prefetch instruction - presumably there was some difference in the compiler and/or the optimisation flags used that caused it to insert prefetch instructions on some machines. > I find it easier and quicker to be overcomplete than delay the process
> when I'm not conversing interactively. Sorry if it was a bit much.
It's a good idea in general, in this case it was just unfortunate that the
one piece of crucial information was buried in another web page :)
Fixed in vex r1324. It would be good if you could verify that the fix works. Works as of: SVN Checkout from Aug 10, 15:14:00 UTC Thanks. :) |