From: Jie <1641861@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1641861] [NEW] fail to correctly emulate FPSCR register on arm
Date: Tue, 15 Nov 2016 07:51:12 -0000 [thread overview]
Message-ID: <20161115075112.3631.29997.malonedeb@soybean.canonical.com> (raw)
Public bug reported:
Hi all, we systematically tested the QEMU implementation for emulating
arm user mode programs. We found that QEMU incorrectly emulate the FPSCR
register. The following the proof of code:
/*********** Beginning of the bug: arm.c **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov r2, %0\n"
"ldr r0, [r2]\n"::"r"((char *)(i0)));;
asm("vmsr fpscr, r0");
asm("mov r2, %0\n"
"vmrs r4, fpscr\n"
"str r4, [r2]\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00};
/*********** End fo the bug **********/
When the program is compiled into arm binary code and running on a real
arm machine, and running in qemu, we have the following result
$ arm-linux-gnueabihf-gcc arm.c -o arm -static
$ ./arm
000000000000000000000000fff7009f
$ qemu-arm arm
000000000000000000000000ffffffff
According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be
reserved as zero. However, arm qemu fails to keep these bits to be zero:
these bits can be actually modified in QEMU.
QEMU version is 2.7.0. The operating system is Linux 3.13.0. x86_64.
Thanks!
** Affects: qemu
Importance: Undecided
Status: New
** Description changed:
Hi all, we systematically tested the QEMU implementation for emulating
arm user mode programs. We found that QEMU incorrectly emulate the FPSCR
register. The following the proof of code:
/*********** Beginning of the bug: arm.c **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char o[0x10];
int main() {
- int k = 0;
- asm("mov r2, %0\n"
- "ldr r0, [r2]\n"::"r"((char *)(i0)));;
- asm("vmsr fpscr, r0");
- asm("mov r2, %0\n"
- "vmrs r4, fpscr\n"
- "str r4, [r2]\n"::"r"((char *)(o)));;
- for (k = 0; k < 0x10; k++)
- printf("%02x", o[0x10 - 1 - k]);
- printf("\n");
+ int k = 0;
+ asm("mov r2, %0\n"
+ "ldr r0, [r2]\n"::"r"((char *)(i0)));;
+ asm("vmsr fpscr, r0");
+ asm("mov r2, %0\n"
+ "vmrs r4, fpscr\n"
+ "str r4, [r2]\n"::"r"((char *)(o)));;
+ for (k = 0; k < 0x10; k++)
+ printf("%02x", o[0x10 - 1 - k]);
+ printf("\n");
}
unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00};
/*********** End fo the bug **********/
When the program is compiled into arm binary code and running on a real
arm machine, and running in qemu, we have the following result
$ arm-linux-gnueabihf-gcc arm.c -o arm -static
$ ./arm
000000000000000000000000fff7009f
$ qemu-arm arm
000000000000000000000000ffffffff
According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be
reserved as zero. However, arm qemu fails to keep these bits to be zero:
these bits can be actually modified in QEMU.
+ QEMU version is 2.7.0. The operating system is Linux 3.13.0. x86_64.
+
Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1641861
Title:
fail to correctly emulate FPSCR register on arm
Status in QEMU:
New
Bug description:
Hi all, we systematically tested the QEMU implementation for emulating
arm user mode programs. We found that QEMU incorrectly emulate the
FPSCR register. The following the proof of code:
/*********** Beginning of the bug: arm.c **********/
int printf(const char *format, ...);
unsigned char i0[0x10];
unsigned char o[0x10];
int main() {
int k = 0;
asm("mov r2, %0\n"
"ldr r0, [r2]\n"::"r"((char *)(i0)));;
asm("vmsr fpscr, r0");
asm("mov r2, %0\n"
"vmrs r4, fpscr\n"
"str r4, [r2]\n"::"r"((char *)(o)));;
for (k = 0; k < 0x10; k++)
printf("%02x", o[0x10 - 1 - k]);
printf("\n");
}
unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00};
/*********** End fo the bug **********/
When the program is compiled into arm binary code and running on a
real arm machine, and running in qemu, we have the following result
$ arm-linux-gnueabihf-gcc arm.c -o arm -static
$ ./arm
000000000000000000000000fff7009f
$ qemu-arm arm
000000000000000000000000ffffffff
According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be
reserved as zero. However, arm qemu fails to keep these bits to be
zero: these bits can be actually modified in QEMU.
QEMU version is 2.7.0. The operating system is Linux 3.13.0. x86_64.
Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1641861/+subscriptions
next reply other threads:[~2016-11-15 8:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 7:51 Jie [this message]
2016-11-28 9:22 ` [Qemu-devel] [Bug 1641861] Re: fail to correctly emulate FPSCR register on arm Peter Maydell
2017-11-06 14:41 ` [Qemu-devel] [Bug 1641861] Re: ARM QEMU doesn't enforce that RES0 bits in FPSCR are non-writeable Peter Maydell
2020-11-10 15:59 ` Peter Maydell
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=20161115075112.3631.29997.malonedeb@soybean.canonical.com \
--to=1641861@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/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).