https://bugs.kde.org/show_bug.cgi?id=476465
Rob Bresalier <rob.bresal...@nokia.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rob.bresal...@nokia.com
--- Comment #12 from Rob Bresalier <rob.bresal...@nokia.com> ---
I believe I ran into this issue. I applied the patch and my application gets
past it, although I don't know 100% if it is correct. Would be nice if this
could get reviewed and merged into the valgrind release.
I am using ARM Neoverse N2 CPU core:
https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-octeon-10-dpu-platform-product-brief.pdf
According to SIGILL diagnostic the unhandled instruction is: 0xB8BFC000
When I decode this instruction using this link:
https://armconverter.com/?disasm&code=00C0BFB8
I see it is also ldapr instruction:
ldapr w0, [x0]
My backtrace looks like this:
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xB8BFC000
disInstr(arm64): 1011'1000 1011'1111 1100'0000 0000'0000
==3466== valgrind: Unrecognised instruction at address 0xc5a7330.
==3466== at 0xC5A7330: load (core_arch_ops_gcc_aarch64.hpp:857)
==3466== by 0xC5A7330: load (core_ops_gcc_atomic.hpp:86)
==3466== by 0xC5A7330: load (atomic_impl.hpp:473)
==3466== by 0xC5A7330:
boost::thread_detail::enter_once_region(boost::once_flag&) (once_atomic.cpp:39)
==3466== by 0xC5A1187: call_once<void (&)()> (once_atomic.hpp:123)
==3466== by 0xC5A1187:
boost::detail::set_current_thread_data(boost::detail::thread_data_base*)
(thread.cpp:160)
==3466== by 0xC5A44F3: thread_proxy (thread.cpp:174)
==3466== by 0xC837B97: start_thread (pthread_create.c:481)
==3466== by 0xD00199B: thread_start (clone.S:79)
==3466== Your program just tried to execute an instruction that Valgrind
==3466== did not recognise. There are two possible reasons for this.
==3466== 1. Your program has a bug and erroneously jumped to a non-code
==3466== location. If you are running Memcheck and you just saw a
==3466== warning about a bad jump, it's probably your program's fault.
==3466== 2. The instruction is legitimate but Valgrind doesn't handle it,
==3466== i.e. it's Valgrind's fault. If you think this is the case or
==3466== you are not sure, please let us know and we'll try to fix it.
==3466== Either way, Valgrind will now raise a SIGILL signal which will
==3466== probably kill your program.
==3466==
==3466== Process terminating with default action of signal 4 (SIGILL): dumping
core
--
You are receiving this mail because:
You are watching all bug changes.
