From: Stefan Weil <weil@mail.berlios.de>
To: Thiemo Seufer <ths@networkno.de>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction
Date: Sat, 17 Mar 2007 12:37:49 +0100 [thread overview]
Message-ID: <45FBD30D.6070403@mail.berlios.de> (raw)
In-Reply-To: <20070317004628.GE25863@networkno.de>
So an emulation has several options:
1. Show undefined behaviour (this is what it does today).
2. Emulate the behaviour of existing CPUs as far as possible.
As different CPUs behave different, this must depend on the
current CPU.
3. Display an error message.
The current solution (1) is not good, because users get crashes
and don't know the reason, and experienced users spend a lot of
time with debugging (at least I did).
Solution (2) is needed to run existing binary code.
Solution (3) is the minimum I expect of an emulation like QEMU.
I prefer a mix of solutions (2) and (3): display a message and
try to emulate the original behaviour.
Do you agree, and would you accept patches which implement this?
Stefan
PS. Emulation of undefined instructions / undefined behaviour has
a long tradition. In the old Z80 and 8086 days, it was
something like a game to analyse and use them :-)
Thiemo Seufer schrieb:
> Stefan Weil wrote:
>> QEMU MIPS emulation fails with code using "illegal" commands
>> in the delay slot of a branch.
>>
>> I had an endless loop with QEMU running the firmware of a
>> MIPS based router.
>>
>> MIPS says: branches, jumps, ... instructions should not be
>> placed in the delay slot of a branch or jump.
>>
>> Nevertheless, some routers use this kind of code.
>
> The architecture spec defines this as undefined behaviour. Other
> implementations of MIPS CPUs show funny effects which are hard
> to explain without detailed knowledge of the microarchitecture.
>
>> I wrote a test program to examine the difference between emulation
>> and a real MIPS CPU (see appendices).
>
> I wouldn't be surprised if it starts to fail for some other combinations
> like a mix of branch and branch likely instructions.
>
> (The semantics of a branch delay slot are: The instruction in the delay
> slot is executed, then the branch is executed. Now, when the instruction
> in the delay slot is itself a branch, what will happen to its delay slot?)
>
>
> Thiemo
>
next prev parent reply other threads:[~2007-03-17 11:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-16 23:12 [Qemu-devel] [Bug] MIPS code fails at branch instruction Stefan Weil
2007-03-17 0:46 ` Thiemo Seufer
2007-03-17 11:37 ` Stefan Weil [this message]
2007-03-17 14:31 ` Thiemo Seufer
2007-03-17 18:57 ` Stefan Weil
2007-03-17 20:32 ` Paul Brook
2007-03-19 21:04 ` [Qemu-devel] [Bug] [Patch] " Stefan Weil
2007-03-19 21:34 ` Thiemo Seufer
2007-03-19 22:34 ` Thiemo Seufer
2007-03-20 7:54 ` Alexander Voropay
2007-03-20 9:51 ` Thiemo Seufer
2007-03-20 18:27 ` Stefan Weil
2007-03-25 0:22 ` Thiemo Seufer
2007-03-25 1:43 ` Aurelien Jarno
2007-03-25 12:51 ` Stuart Brady
2007-03-25 16:26 ` Thiemo Seufer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45FBD30D.6070403@mail.berlios.de \
--to=weil@mail.berlios.de \
--cc=qemu-devel@nongnu.org \
--cc=ths@networkno.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).