From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HTQSW-0003at-Rq for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:36:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HTQSW-0003Yh-1b for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:36:08 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTQSV-0003YO-Rx for qemu-devel@nongnu.org; Mon, 19 Mar 2007 17:36:07 -0500 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HTQR0-0000Qm-DA for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:34:34 -0400 Date: Mon, 19 Mar 2007 22:34:49 +0000 Subject: Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction Message-ID: <20070319223449.GK28895@networkno.de> References: <45FB245C.2010900@mail.berlios.de> <20070317143106.GF25863@networkno.de> <45FC3A07.3070302@weilnetz.de> <200703172032.52010.paul@codesourcery.com> <45FEFAC0.4060901@mail.berlios.de> <20070319213445.GJ28895@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070319213445.GJ28895@networkno.de> From: Thiemo Seufer Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org Thiemo Seufer wrote: [snip] > > Patched QEMU HEAD (see appended patch file): > > > > * The code works in a well defined way. An optional message in the log file > > will show the faulty statement. It won't amount to a DoS because it > > is disabled by default. > > Sorry, but I missed the "well defined". What does the jump in the branch > delay slot exactly _do_ now? Where does the PC point to when it was a > conditional branch which wasn't taken? I committed something which cover the rest of your patch, and throws now a RI exception for branch-in-branch-delay-slot. For the AR7 case, could you - add AR7 as a CPU type - handle the interesting cases for AR7 only, after verifying the cornercase behaviour of qemu and real hardware is consistent. The cornercases which come to mind: - conditional vs. unconditional branches - the various condition types - taken vs. non-taken branches - linked vs. non-linked branches - likely vs. non-likely branches - the side effects of j / jal in the delayslot - the value of PC/ra (if it changes) I don't ask for an exhaustive analysis, I just want to see the cases of interest covered, so we can be reasonably sure the qemu results will be useful for other AR7 users as well. Thiemo