|
From: Ashley P. <as...@qu...> - 2005-11-01 18:06:12
|
Hi,
I've just tried compiling up and running valgrind on opteron for the
first time, valgrind runs fine for simple programs like date or ls but
is aborting in our library's due to un-handled instruction. We don't
use elan3 on opterons as it's a little old now so this is elan4 code.
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x11 0x47
==9217== Your program just tried to execute an instruction that Valgrind
==9217== did not recognise. There are two possible reasons for this.
==9217== 1. Your program has a bug and erroneously jumped to a non-code
==9217== location. If you are running Memcheck and you just saw a
==9217== warning about a bad jump, it's probably your program's
fault.
==9217== 2. The instruction is legitimate but Valgrind doesn't handle
it,
==9217== i.e. it's Valgrind's fault. If you think this is the case
or
==9217== you are not sure, please let us know.
==9217== Either way, Valgrind will now raise a SIGILL signal which will
==9217== probably kill your program.
==9217==
==9217== Process terminating with default action of signal 4 (SIGILL):
dumping core
==9217== Illegal opcode at address 0x45A7941
==9217== at 0x45A7941: cmdq_writes (lib_cmdqwrite.h:208)
==9217== by 0x45A80DC: elan4_flush_cmdq_reorder
(lib_cmdq_flush.c:174)
==9217== by 0x4222630: elan_doatomic64 (atomic.c:559)
==9217== by 0x42229FD: elan_atomic64 (atomic.c:585)
==9217== by 0x4234066: elan_baseInit (base.c:802)
==9217== by 0x40006B88: main (bench/tping.c:2064)
The code in question is for writing across the PCI bus and is written in
hand-crafted assembler.
I'm using svn revision 4979 (up to date)
Ashley,
static inline void
cmdq_write16 (E4_uint64 *src, volatile E4_uint64 *dst)
{
#if defined(__i386) || defined(__x86_64)
asm volatile ("movupd 0(%1), %%xmm0\n"
"movupd 16(%1), %%xmm1\n"
"movupd 32(%1), %%xmm2\n"
"movupd 48(%1), %%xmm3\n"
"movupd 64(%1), %%xmm4\n"
"movupd 80(%1), %%xmm5\n"
"movupd 96(%1), %%xmm6\n"
"movupd 112(%1),%%xmm7\n"
"movupd %%xmm0, 0(%0)\n"
"movupd %%xmm1, 16(%0)\n"
"movupd %%xmm2, 32(%0)\n"
"movupd %%xmm3, 48(%0)\n"
"movupd %%xmm4, 64(%0)\n"
"movupd %%xmm5, 80(%0)\n"
"movupd %%xmm6, 96(%0)\n"
"movupd %%xmm7, 112(%0)\n"
: : "r" (dst), "r" (src) : "memory",
"%xmm0", "%xmm1", "%xmm2", "%xmm3",
"%xmm4", "%xmm5", "%xmm6", "%xmm7");
#else
cmdq_write8 (&src[0], &dst[0]);
cmdq_write8 (&src[8], &dst[8]);
#endif
}
|
|
From: Julian S. <js...@ac...> - 2005-11-01 18:48:50
|
> vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x11 0x47 Yeh, this is bug 115116 (see http://bugs.kde.org/show_bug.cgi?id=115116). Will look at it shortly. J |
|
From: Julian S. <js...@ac...> - 2005-11-01 19:02:57
|
Ok, svn up (make sure you get vex r1427) and try again. I was too lazy to spark up my amd64 box so the fix is as-yet untested :-) J |
|
From: Ashley P. <as...@qu...> - 2005-11-02 15:05:55
|
On Tue, 2005-11-01 at 19:03 +0000, Julian Seward wrote: > Ok, svn up (make sure you get vex r1427) and try again. I was too > lazy to spark up my amd64 box so the fix is as-yet untested :-) That fixes it for me. I can now run fairly large applications on these nodes without errors. Ashley, |