https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #29 from Peter Maydell <peter.mayd...@linaro.org> --- 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 we've baked into the translation. One of those state flags is "is CPSR.E set?", so when we later come to check whether we've already translated a code block we won't return one that was translated assuming the "wrong" endianness. (We also use this to be able to generate code that makes assumptions about the current setting of VFP vector length and stride, Thumb condexec bits, and some other stuff that only matters for kernel-mode code emulation.) This avoids the downsides of your options (1) and (2), though it does require that you're doing lookup of code blocks by something other than raw PC, which QEMU does anyway. I agree that rpi's memset implementation is a bit weird, but on the hardware they use (ARM1176) SETEND is pretty nearly free and it turns out to be fastest. They're not going to change it now, it's more likely that the rpi1 will vanish into the mists of history first. -- You are receiving this mail because: You are watching all bug changes.
