|
From: Julian C. <jul...@un...> - 2013-11-27 12:05:19
|
Hi, First off thanks for the amazing work on valgrind and bringing this excellent tool to mips :) I've just found out that the mips port was completed a while ago and have tried to use it on our embedded devices. It works fine on basic Linux commands like 'ls' and 'pwd', but as soon as I use a multi-threaded program (one of our own) I get an unhandled instruction error that looks like this: vex mips->IR: unhandled instruction bytes: 0x0 0x0 0x0 0xE ==3262== valgrind: Unrecognised instruction at address 0x490fc04. ==3262== at 0x490FC04: ??? (in /lib/libstdc++.so.6.0.3) ==3262== by 0x490FBC8: ??? (in /lib/libstdc++.so.6.0.3) .... ==3262== Process terminating with default action of signal 4 (SIGILL): dumping core ==3262== Illegal opcode at address 0x490FC04 ==3262== at 0x490FC04: ??? (in /lib/libstdc++.so.6.0.3) ==3262== by 0x490FBC8: ??? (in /lib/libstdc++.so.6.0.3) I built and configured valgrind with the following configure line to match our the options we use to build for mips: ./configure --prefix=<my-valgrind-install-directory> CFLAGS="-mips32r2 -mtune=24kec -mabi=32 -mlong-calls" --with-pagesize=4 --host-mips-linux I also patched the source to disable large file support to match our environment - http://git.buildroot.net/buildroot/plain/package/valgrind/valgrind- largefile.patch We are using uclibc 0.9.28 running on Linux kernel 3.4.52. The MIPS processor is a MIPS 24Kc and the GCC toolchain version is gcc 3.4.4 I am at the limit of my knowledge with debugging this problem. Any help or guidance you can give would be greatly appreciated. Many thanks, Julian |
|
From: John R.
|
> vex mips->IR: unhandled instruction bytes: 0x0 0x0 0x0 0xE > ==3262== valgrind: Unrecognised instruction at address 0x490fc04. > ==3262== at 0x490FC04: ??? (in /lib/libstdc++.so.6.0.3) > ==3262== by 0x490FBC8: ??? (in /lib/libstdc++.so.6.0.3) > We are using uclibc 0.9.28 running on Linux kernel 3.4.52. The MIPS > processor is a MIPS 24Kc and the GCC toolchain version is gcc 3.4.4 Thank you for a good report, including those details about the environment. To make it even better, which version of valgrind? ($ valgrind --version) valgrind-3.9.0 was released recently. Is your CPU running big-endian or little-endian? One way interprets ".byte 0,0,0,0xe" as a 'jal' instruction. For the other way, GNU gdb 6.8 does not recognize it, which may mean the instruction is an architectural extension or CPU-specific function: GNU gdb 6.8 (gdb) x/i 0 0x0 <_start>: jal 0x8000000 0x4 <_start+4>: 0xe (gdb) x/2x 0 0x0 <_start>: 0x0e000000 0x0000000e Your next step is to file a bug report so that the developers don't lose track of the problem. Go to https://bugs.kde.org/enter_bug.cgi?product=valgrind , then enter the same info there as you posted here. This will maximize the probability that valgrind developers will see and solve the problem. -- |
|
From: Julian C. <jul...@un...> - 2013-11-28 08:58:09
|
John Reiser <jreiser <at> BitWagon.com> writes: > > > vex mips->IR: unhandled instruction bytes: 0x0 0x0 0x0 0xE > > ==3262== valgrind: Unrecognised instruction at address 0x490fc04. > > ==3262== at 0x490FC04: ??? (in /lib/libstdc++.so.6.0.3) > > ==3262== by 0x490FBC8: ??? (in /lib/libstdc++.so.6.0.3) > > > We are using uclibc 0.9.28 running on Linux kernel 3.4.52. The MIPS > > processor is a MIPS 24Kc and the GCC toolchain version is gcc 3.4.4 > > Thank you for a good report, including those details about the environment. > To make it even better, which version of valgrind? ($ valgrind --version) > valgrind-3.9.0 was released recently. > > Is your CPU running big-endian or little-endian? One way interprets > ".byte 0,0,0,0xe" as a 'jal' instruction. For the other way, GNU gdb 6.8 > does not recognize it, which may mean the instruction is an architectural > extension or CPU-specific function: > GNU gdb 6.8 > (gdb) x/i 0 > 0x0 <_start>: jal 0x8000000 > 0x4 <_start+4>: 0xe > (gdb) x/2x 0 > 0x0 <_start>: 0x0e000000 0x0000000e > > Your next step is to file a bug report so that the developers don't lose > track of the problem. Go to https://bugs.kde.org/enter_bug.cgi? product=valgrind , > then enter the same info there as you posted here. This will maximize > the probability that valgrind developers will see and solve the problem. > Thanks for the very quick reply. I've filed a bug report as you suggested here https://bugs.kde.org/show_bug.cgi?id=328147 The extra information you requested is included in the bug report and for completeness I'll repeat it here. The valgrind version is 3.9.0, we are running big-endian on the CPU. There is a suggestion from a colleague that there may be an issue to do with Native POSIX Linux Thread, support for which does not come into uClibc until 0.9.32 (we're running 0.9.28) but I have no experience in this area. Thanks, Julian |