diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-03 12:04:13 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-03 12:04:13 +0000 |
| commit | 256709d2eb3fd80d768a99964be5caa61effa2a0 (patch) | |
| tree | 05b2352fba70923126836a64b6a0de43902e976a /results/classifier/105/other/1549654 | |
| parent | 2ab14fa96a6c5484b5e4ba8337551bb8dcc79cc5 (diff) | |
| download | qemu-analysis-256709d2eb3fd80d768a99964be5caa61effa2a0.tar.gz qemu-analysis-256709d2eb3fd80d768a99964be5caa61effa2a0.zip | |
add new classifier result
Diffstat (limited to 'results/classifier/105/other/1549654')
| -rw-r--r-- | results/classifier/105/other/1549654 | 303 |
1 files changed, 303 insertions, 0 deletions
diff --git a/results/classifier/105/other/1549654 b/results/classifier/105/other/1549654 new file mode 100644 index 000000000..6473c8f34 --- /dev/null +++ b/results/classifier/105/other/1549654 @@ -0,0 +1,303 @@ +other: 0.733 +instruction: 0.673 +device: 0.653 +assembly: 0.639 +vnc: 0.632 +semantic: 0.631 +KVM: 0.605 +graphic: 0.565 +boot: 0.522 +socket: 0.504 +mistranslation: 0.487 +network: 0.428 + +qemu-system-arm emulator + +Hi, + +I don't know if this is a bug or a feature in new QEMU software. I was following an online tutorial using QEMU to develop a simple bare-metal program for qemu-system-arm. I decided to try a more recent software and I got surprised when I found the small code can not run on newer QEMU software (all newer than 2.0.0) but can run on the old QEMU from Ubuntu (Debian 2.0.0+dfsg-2ubuntu1.22) and the stock version from website. After putting the qemu-system-arm in single step and saving the log, the following is the output which you can see the 1st instruction stores R3 at [fp, #-8] and the second instruction can not restores the value from the same address to R0: + +0x00010074: e50b3008 str r3, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010074 +PSR=400001d3 -Z-- A S svc32 +---------------- +IN: kmain +0x00010078: e51b0008 ldr r0, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010078 +PSR=400001d3 -Z-- A S svc32 +---------------- +IN: kmain +0x0001007c: ebffffe3 bl 0x10010 + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=0001007c +PSR=400001d3 -Z-- A S svc32 + +-------------------------------------- +Meanwhile the older version of QEMU 2.0.0 does this very well and can execute the program normally: + +0x00010074: e50b3008 str r3, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010074 +PSR=400001d3 -Z-- A svc32 +---------------- +IN: kmain +0x00010078: e51b0008 ldr r0, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010078 +PSR=400001d3 -Z-- A svc32 +---------------- +IN: kmain +0x0001007c: ebffffe3 bl 0x10010 + +R00=0001008c R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=0001007c +PSR=400001d3 -Z-- A svc32 +---------------- + +The command line to use was: + +qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 1 -m 64M -nographic -kernel kernel.elf -singlestep -D file.log -d in_asm,cpu + +The kernel.elf is a simple program (elf) file, created from two sources: + +boot.S: + +.global _RESET +_RESET: +LDR sp, =_STACK +BL kmain +B . + +And kernel.c: + +# define UART0_MEM 0x10009000 + +volatile unsigned int * const UART0 = (unsigned int *) UART0_MEM; +void dprint(const char* message){ + while(*message != 0) { + *UART0=*message; + ++message; + } +} +void kmain() { + const char *hi="Hello!"; + dprint(hi); +}; + +The linker scripts is: +ENTRY(_RESET) +SECTIONS +{ + . = 0x10000; + .boot . : { boot.o(.text) } + .text : { *(.text) } + .data : { *(.data) } + .bss : { *(.bss COMMON) } + . = ALIGN(8); + . = . + 0x1000; /* 4kB of stack memory */ + _STACK = .; +} + +This error cases the dprint function to find *message as 0 and do not print the output in newer QEMU software. + +Thank you for consideration. + +> the 1st instruction stores R3 at [fp, #-8] and the second instruction can not restores the value from the same address + +In bare metal code this usually means you're trying to store to an address which does not actually have any RAM in it. + +Here R13=00011088, and for the vexpress-a9 board that has a NOR flash device at it, not RAM. RAM starts at 0x60000000. If you link your program to use the RAM at the RAM address you should find it works better. + +(In earlier versions of QEMU we did have RAM at the 0 address. In real hardware the 0 address is a remappable range which may point to flash or to RAM depending on board configuration. For QEMU we don't model the reconfigurability, and we picked flash because this allows us to run various BIOS-style ROM images. It does unfortunately mean we broke a few odd bare metal images which were relying on the RAM being mapped in there.) + + +Dear Peter, + +You are right, I changed the address to 0x60010000 and now it works. The +program was writing out of SRAM and it was working on older QEMU versions +but not the new ones. + +Thank you for your help! + +Best regards, +Mahdi + +On Thu, Feb 25, 2016 at 3:01 PM Peter Maydell <email address hidden> +wrote: + +> > the 1st instruction stores R3 at [fp, #-8] and the second instruction +> can not restores the value from the same address +> +> In bare metal code this usually means you're trying to store to an +> address which does not actually have any RAM in it. +> +> Here R13=00011088, and for the vexpress-a9 board that has a NOR flash +> device at it, not RAM. RAM starts at 0x60000000. If you link your +> program to use the RAM at the RAM address you should find it works +> better. +> +> (In earlier versions of QEMU we did have RAM at the 0 address. In real +> hardware the 0 address is a remappable range which may point to flash or +> to RAM depending on board configuration. For QEMU we don't model the +> reconfigurability, and we picked flash because this allows us to run +> various BIOS-style ROM images. It does unfortunately mean we broke a few +> odd bare metal images which were relying on the RAM being mapped in +> there.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1549654 +> +> Title: +> qemu-system-arm emulator +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I don't know if this is a bug or a feature in new QEMU software. I was +> following an online tutorial using QEMU to develop a simple bare- +> metal program for qemu-system-arm. I decided to try a more recent +> software and I got surprised when I found the small code can not run +> on newer QEMU software (all newer than 2.0.0) but can run on the old +> QEMU from Ubuntu (Debian 2.0.0+dfsg-2ubuntu1.22) and the stock version +> from website. After putting the qemu-system-arm in single step and +> saving the log, the following is the output which you can see the 1st +> instruction stores R3 at [fp, #-8] and the second instruction can not +> restores the value from the same address to R0: +> +> 0x00010074: e50b3008 str r3, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010074 +> PSR=400001d3 -Z-- A S svc32 +> ---------------- +> IN: kmain +> 0x00010078: e51b0008 ldr r0, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010078 +> PSR=400001d3 -Z-- A S svc32 +> ---------------- +> IN: kmain +> 0x0001007c: ebffffe3 bl 0x10010 +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=0001007c +> PSR=400001d3 -Z-- A S svc32 +> +> -------------------------------------- +> Meanwhile the older version of QEMU 2.0.0 does this very well and can +> execute the program normally: +> +> 0x00010074: e50b3008 str r3, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010074 +> PSR=400001d3 -Z-- A svc32 +> ---------------- +> IN: kmain +> 0x00010078: e51b0008 ldr r0, [fp, #-8] +> +> R00=00000000 R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=00010078 +> PSR=400001d3 -Z-- A svc32 +> ---------------- +> IN: kmain +> 0x0001007c: ebffffe3 bl 0x10010 +> +> R00=0001008c R01=00000000 R02=00000000 R03=0001008c +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00011094 +> R12=00000000 R13=00011088 R14=00010008 R15=0001007c +> PSR=400001d3 -Z-- A svc32 +> ---------------- +> +> The command line to use was: +> +> qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 1 -m 64M -nographic +> -kernel kernel.elf -singlestep -D file.log -d in_asm,cpu +> +> The kernel.elf is a simple program (elf) file, created from two +> sources: +> +> boot.S: +> +> .global _RESET +> _RESET: +> LDR sp, =_STACK +> BL kmain +> B . +> +> And kernel.c: +> +> # define UART0_MEM 0x10009000 +> +> volatile unsigned int * const UART0 = (unsigned int *) UART0_MEM; +> void dprint(const char* message){ +> while(*message != 0) { +> *UART0=*message; +> ++message; +> } +> } +> void kmain() { +> const char *hi="Hello!"; +> dprint(hi); +> }; +> +> The linker scripts is: +> ENTRY(_RESET) +> SECTIONS +> { +> . = 0x10000; +> .boot . : { boot.o(.text) } +> .text : { *(.text) } +> .data : { *(.data) } +> .bss : { *(.bss COMMON) } +> . = ALIGN(8); +> . = . + 0x1000; /* 4kB of stack memory */ +> _STACK = .; +> } +> +> This error cases the dprint function to find *message as 0 and do not +> print the output in newer QEMU software. +> +> Thank you for consideration. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1549654/+subscriptions +> + + |