--- 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.