[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw

https://bugs.kde.org/show_bug.cgi?id=360425 Peter Maydell changed: What|Removed |Added CC|

[valgrind] [Bug 366345] Dirty compile from m_libcbase.c and vgdb-invoker-ptrace.c

https://bugs.kde.org/show_bug.cgi?id=366345 Peter Maydell changed: What|Removed |Added CC|

[valgrind] [Bug 366464] disInstr(arm): unhandled instruction: 0xF1010200

https://bugs.kde.org/show_bug.cgi?id=366464 Peter Maydell changed: What|Removed |Added CC|

[valgrind] [Bug 366464] disInstr(arm): unhandled instruction: 0xF1010200

https://bugs.kde.org/show_bug.cgi?id=366464 --- Comment #4 from Peter Maydell --- (In reply to Jeffrey Walton from comment #3) > Is there a way to get Valgrind's portion of the bug tracker to return search > results that are no longer open? Or at least include the ones

[valgrind] [Bug 361726] WARNING:unhandled syscall on ppc64

https://bugs.kde.org/show_bug.cgi?id=361726 Peter Maydell changed: What|Removed |Added CC|

[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian

https://bugs.kde.org/show_bug.cgi?id=322935 --- Comment #33 from Peter Maydell --- (In reply to Mark Wielaard from comment #32) > valgrind should already intercept the memcmp from glibc. This one however is > in a different library libcofi_rpi.so which looks like some

[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian

https://bugs.kde.org/show_bug.cgi?id=322935 --- Comment #29 from Peter Maydell --- The way QEMU's JIT handles this kind of thing is that we track each translated code block by (start PC, cpu state flags), where the flags track the subset of the CPU's current state that

[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian

https://bugs.kde.org/show_bug.cgi?id=322935 --- Comment #31 from Peter Maydell --- If your JIT architecture doesn't permit a QEMU-style approach I would be tempted to go with "implement SETEND to throw away JITted code and print a warning about poor performance". At the

[valgrind] [Bug 362934] [AsusWRT] Arm v7 illegal instruction

https://bugs.kde.org/show_bug.cgi?id=362934 Peter Maydell changed: What|Removed |Added CC|

[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)

https://bugs.kde.org/show_bug.cgi?id=369459 Peter Maydell changed: What|Removed |Added CC|

[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)

https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #8 from Peter Maydell --- FWIW QEMU is switching to emulating atomics (including ll/sc) via a common "cmpxchg" IR operation (which is then implemented in the backend via an ll/sc loop or whatever the host CPU has).

[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)

https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #14 from Peter Maydell --- I think the assertion about "real world code not caring" is based on some popular CPUs not having an ll/sc combination (like x86!), and so portable atomicity primitives can't assume you