Re: [Valgrind-users] Application crashes on MIPS cpu if we valgrind it

[John R. <jr...@bi...>]

> ==3269== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info 
> ==3269== valgrind: Unrecognised instruction at address 0x40c038.
> ==3269==    at 0x40C038: _dl_aux_init (in /tmp/wqf/Install/bin/test)
> ==3269==    by 0x400400: (below main) (in /tmp/wqf/Install/bin/test)

> ==4441== valgrind: Unrecognised instruction at address 0x4016fd8.
> ==4441==    at 0x4016FD8: ??? (in /lib/ld-2.11.1.so)
> ==4441==    by 0x4000E5C: ??? (in /lib/ld-2.11.1.so)

Your ld-2.11.1.so uses some instruction opcode(s) that valgrind (memcheck; VEX)
does not implement yet.  You have also encountered a usability bug in memcheck,
namely memcheck 3.8.1 does not print the actual instruction bytes, and therefore
it is hard for anyone to discover exactly what is necessary to make memcheck work
on your program.  The memcheck bug is https://bugs.kde.org/show_bug.cgi?id=309323.
Please add a comment there "I encountered this bug, also."  Copy+paste those
two error reports above [7 or 8 lines] into your new comment at bug 309323.

Meanwhile, https://bugs.kde.org/show_bug.cgi?id=309323#c5 says that the source
for memcheck has been changed to print the instruction bytes.  However, no release
has been made that incorporates the changes.  So, you could try checking out
the current source tree, then building and running your own local version of memcheck.
If "successful", then at least you will know what opcode is missing from memcheck/VEX.

That's the first half of what needs to be done.  Then you should look up that opcode
in the MIPS documentation, and file another bug against memcheck: "Please implement
opocde 0xYYYYYYYY ("foo") for MIPS-74K."  Give the information about where that
opcode appears: ld-2.11.1, routine _dl_aux_init, etc.

You can also find the opcode by using a disassembler and/or debugger.
Disassemble the 8 instructions (4 before, 4 after) which surround addresses
0x40c038 and 0x4016fd8.  The reported address is the actual address in
the static linked version.  The reported address probably is 0x4000000 higher
than in the shared library /lib/ld-2.11.1.

All that will not solve the problem, but it will identify precisely what the problem _is_.
Then you need to convince the valgrind(VEX) maintainers to implement the missing opcode,
or you need to re-write the code to avoid using that instruction.

--