From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GFDZZ-0000L8-UC for qemu-devel@nongnu.org; Mon, 21 Aug 2006 13:28:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GFDZX-0000Id-SR for qemu-devel@nongnu.org; Mon, 21 Aug 2006 13:28:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFDZW-0000I0-Eg for qemu-devel@nongnu.org; Mon, 21 Aug 2006 13:28:22 -0400 Received: from [64.233.182.187] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GFDgw-0008Uf-Ts for qemu-devel@nongnu.org; Mon, 21 Aug 2006 13:36:03 -0400 Received: by nf-out-0910.google.com with SMTP id m19so2284393nfc for ; Mon, 21 Aug 2006 10:28:20 -0700 (PDT) Message-ID: <9f4a5ebe0608211028v37cc0c7aidec043ce414060bb@mail.gmail.com> Date: Mon, 21 Aug 2006 10:28:20 -0700 From: "Chris McNett" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21059_10487780.1156181300305" Subject: [Qemu-devel] Bug: ARM target uses an inconsistent offset when storing R15 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org ------=_Part_21059_10487780.1156181300305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, According to the ARM Architecture Reference Manual: "An implementation must use the same offset for all STR and STM instructions that store R15. It cannot use 8 for some of them and 12 for others." Qemu appears to be inconsistent in this behavior. Specifically, the following two instructions: stmdb sp!, {pc} str pc, [sp, #-4] use different offsets. The following test code will verify this: #include int main(void) { unsigned long x, y; asm volatile( "sub r1, pc, #4\n" "stmdb sp!, {pc}\n" "ldmia sp!, {r2}\n" "sub %0, r2, r1" : "=r"(x) : : "r1", "r2"); asm volatile( "sub r1, pc, #4\n" "str pc, [sp, #-4]\n" "ldr r2, [sp, #-4]\n" "sub %0, r2, r1" : "=r"(y) : : "r1", "r2"); printf("%ld %ld\n", x, y); } On qemu, the code prints "12 8". On an XScale processor, the code prints "8 8". In the qemu-0.8.2 sources, one fix for this is to change lines 1727-1728 of target-arm/translate.c from: /* special case: r15 = PC + 12 */ val = (long)s->pc + 8; to: /* special case: r15 = PC + 8 */ val = (long)s->pc + 4; Once this change is made, the test code will print out "8 8" as XScale hardware does. As an alternative, the offset used in other store instructions could be changed to 12 instead of 8. Thanks, Chris McNett ------=_Part_21059_10487780.1156181300305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi,

According to the ARM Architecture Reference Manual:
"An implementation must use the same offset for all STR and STM instructions that store R15.  It cannot use 8 for some of them and 12 for others."

Qemu appears to be inconsistent in this behavior.  Specifically, the following two instructions:

 stmdb sp!, {pc}
 str pc, [sp, #-4]

use different offsets.

The following test code will verify this:

#include <stdio.h>

int main(void) {
 unsigned long x, y;
 asm volatile(
 "sub r1, pc, #4\n"
 "stmdb sp!, {pc}\n"
 "ldmia sp!, {r2}\n"
 "sub %0, r2, r1" :
 "=r"(x) :
 :
 "r1", "r2");

 asm volatile(
 "sub r1, pc, #4\n"
 "str pc, [sp, #-4]\n"
 "ldr r2, [sp, #-4]\n"
 "sub %0, r2, r1" :
 "=r"(y) :
 :
 "r1", "r2");
 printf("%ld %ld\n", x, y);
}

On qemu, the code prints "12 8".  On an XScale processor, the code prints "8 8".

In the qemu-0.8.2 sources, one fix for this is to change lines 1727-1728 of target-arm/translate.c from:
                                /* special case: r15 = PC + 12 */
                                val = (long)s->pc + 8;
to:
                                /* special case: r15 = PC + 8 */
                                val = (long)s->pc + 4;

Once this change is made, the test code will print out "8 8" as XScale hardware does.

As an alternative, the offset used in other store instructions could be changed to 12 instead of 8.

Thanks,
Chris McNett

------=_Part_21059_10487780.1156181300305--