For what is worth, this was fixed in the Android emulator with the following patch:
http://android.git.kernel.org/?p=platform/external/qemu.git;a=commit;h=01e9608cb62901d13b330f851a260a2082e81a06 <http://android.git.kernel.org/?p=platform/external/qemu.git;a=commit;h=01e9608cb62901d13b330f851a260a2082e81a06>And sorry, we don't have any time to adapt this to the upstream QEMU sources right now. Hope this helps On Fri, Jan 7, 2011 at 5:12 PM, Peter Maydell <peter.mayd...@linaro.org>wrote: > On 7 January 2011 16:01, Aurelien Jarno <aurel...@aurel32.net> wrote: > > In overall I think it's the correct approach to fix the issue, this is > > a really good cleanup. I have tested this patch series, and it clearly > > improve armv7 support. However I am surprised it doesn't fix the issue > > mentioned in https://bugs.launchpad.net/qemu/+bug/581335 , which seems > > to be the same issue. Executing the testcase still returns 1 instead of > > 0 on QEMU. > > I think that bug is a different problem, which is that when we take > an unexpected exception we don't correctly reset the condexec bits > when restarting. I think that the right way to fix that is for > gen_pc_load() > to restore not just the PC but also the condexec bits (in the same way > that on MIPS we restore env->hflags). > > I haven't quite managed to work that up into a patch yet, though > (figuring out exactly where we do and don't need to output code > to update the condexec bits is a bit tricky). I have a long plane flight > on Sunday though so might have another hack at it then :-) > > -- PMM > >
