Re: ARM Simulator Bug?

[Richard Earnshaw <rearnsha@arm.com>]

> Hi Richard,
> 
> >Try using an 
> >
> >	LDR r0, =__thumb
> >
> 
> This command places the correct value into R0 for the BX command, but the bug
> within the simulator is still present. 
> 
> Take the following code as an example.
> 
> 0000005c <TST_start>:
>   5c:   e3a0da12        mov     sp, #73728      ; 0x12000
>   60:   e59f00a4        ldr     r0, [pc, #164]  ; 10c <IRQ_Interrupt+0x50>
>   64:   e12fff10        bx      r0
> 
> 00000068 <__start_of_thumb>:
> 
> void    IRQ_Interrupt(void);
> 
> int main()
> {
>   68:   b580            push    {r7, lr}
>   6a:   466f            mov     r7, sp
>   6c:   b082            sub     sp, #8
> 
> If I place a breakpoint at 0x6c and run the code gdb loses itself, i.e. if I
> interrupt it with ctrl-c it says the PC is 0x0580fa70 or some thing similar.
> Again, if I place a breakpoint at 0x5c, I can single step successfully. If I
> single step to 0x68 and place a breakpoint at 0x6c and continue, gdb loses itself
> again.
> 
> This problem only occurs when I attempt to use thumb. If I remove the bx command
> and compile my C file in ARM mode the simulator works perfectly.

Hmm, you are building *all* of your source with -g aren't you?  gdb can 
get very confused if it doesn't know whether it's debugging ARM or Thumb 
code and it defaults to ARM when it doesn't know (another side-effect of 
no mapping symbols).

Another thing to consider:

Is the processor taking an abort on the push instruction and jumping into 
the abort handler?  Try putting an a breakpoint at address 0x00000010.  
Alternatively, check the value of SP before stepping the instruction.

> 
> Is it possible to see which commands the simulator is executing? 
> 

I'm not aware of any simple way to do that.  I agree that there are times 
when it would be useful.

R.