[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Questions on ARM port
From: |
Schwarz, Konrad |
Subject: |
[Qemu-devel] Questions on ARM port |
Date: |
Tue, 14 Mar 2006 14:28:25 +0100 |
Hello,
the Newlib crt0.S
file for ARM starts off by initializing the stack pointers for the different ARM
modes (FIQ, IRQ, supervisor, etc.) with the help of r3.
e.g., this is the
disassembly as produced by GDB:
Dump of assembler code for function
start:
0x00008224 <start+0>: ldr
r3, [pc, #208] ; 0x82fc <$d+4>
0x00008228
<start+4>: cmp r3, #0 ;
0x0
0x0000822c <start+8>: ldreq r3, [pc,
#196] ; 0x82f8 <$d>
0x00008230 <start+12>:
msr CPSR_c, #209 ; 0xd1
0x00008234
<start+16>: mov sp, r3
0x00008238
<start+20>: sub r10, sp, #4096 ;
0x1000
0x0000823c <start+24>: mov r3,
r10
0x00008240 <start+28>: msr CPSR_c,
#215 ; 0xd7
0x00008244 <start+32>:
mov sp, r3
...
Basically, r3 is initialized by <start+8> (to
0x80000, in my case). The next instruction (at <start+12>) switches
the mode to FIQ. After single steping over this in QEMU (via GDB si),
r3 no longer contains what it had before (0x80000), instead, it is set to 0.
If I manually fix this (via set $r3=0x80000), then at the next mode switch (at
<start+28>) r3 is changed incorrectly to zero again.
Is this
my fault or what is happening?
I am
invoking qemu as
arm-softmmu/qemu-system-arm -S -s -M
altera_excalibur -m 64 -net none -nographic -kernel
../projekte/L6/node-arm/libsys/test-io/libsys_test_uart -monitor null -parallel
null -serial null
(where
altera_excalibur is a machine that I have added and would like to
debug).
Regards,
Konrad
Schwarz
Konrad Schwarz.vcf
Description: Konrad Schwarz.vcf
- [Qemu-devel] Questions on ARM port,
Schwarz, Konrad <=