a small bug in the arm simulator

a small bug in the arm simulator

[Jens-Christian Lache]

Hi everybody!

Some time ago I have complained, that the arm simulator does not know software
traps. I am able to simulate them now with the following steps:

1.) Step until the "swi" instruction, but do not execute it
(grap the register window from insight)
2.) Set mode bits in cpsr to b00011
for example 0x800000d0 -> 0x800000d3
3.) Set pc to 0x8
4.) stepi
5.) (we should now be in the swi_wrapper) set lr to the value from the swi +4
6.) if somewhere the spsr should be read into a gp reg, adjust this value to
     the old cpsr

This should work fine.

I use the same way to simlulate interrupts. If I compile my project for the
simulator, I load the address of the interrupt wrapper directly instead
obtaining it from the AIC.

It looks the following

1.) Run prog to an arbitry location and grap the reg window from insight
2.) Set mode bits in cpsr to b00010
3.) Set pc to 0x18
4.) stepi
5.) (we should now be in the tc0_interrupt_handler) set lr to the value from the
    last instruction + 4 
6.) if somewhere the spsr should be read into a gp reg, adjust this
     value to the old cpsr

This work fine so far. The assembler interrupt handler sets lr to
interrupt_end_os_schedule_0 in my case and jumps to the approriate 
C++ function. When this function is done it jumps to the value of lr. This
looks the following:

- 0x201aa80 <interrupt_end_os_schedule_0>:	 ldmia sp!, {r1, r2, r3, r12,lr} 
- 0x201aa84 <interrupt_end_os_schedule_0+4>:	 mrs	r0,CPSR 
- 0x201aa88 <interrupt_end_os_schedule_0+8>:	 bic r0,r0, #31; 0x1f 
- 0x201aa8c <interrupt_end_os_schedule_0+12>: 	 orr r0, r0, #146	; 0x92
- 0x201aa90 <interrupt_end_os_schedule_0+16>:	 msr	CPSR_fc, r0

The bug is located in 0x201aa90. It is not writing anything at all to the cpsr.

Can anybody explain my, how to compile gdb with debug symbols turned on?

Regards,

Jens-Christian

-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: Re (2nd): a small bug in the arm simulator

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5379 bytes --]

Hi!
Am Fre, 23 Feb 2001 schrieben Sie:
> 
> Hi Jens-Christian,
> 
> This time, I read your whole mail and I have some remarks:
> 
> 
>   1. Your translations of cpsr in binary forms are not exact. Mode bits are always
>      beginning with 1 (b1xxxx).

You are right. I set the cpsr to 0x800000d2 if it had been 0x800000d0

>   2. I hope it is a typing error else if you set the current mode to b00010 (to
>      simulate interrupts), you would corrupt the state machine of the ARM processor
>      simulator (state machine that allows the ARM processor not to change CPSR when
>      you write it, for example if the current mode is user).

You are right. I set the cpsr to 0x800000d2 if it had been 0x800000d0

>   3. I do not see the interest of the assembler code you trace that set the current
>      mode to the IRQ mode, which is the mode you are already in.
No. My interrupt handler switches to mode system before launching the c++
function. In the interrupt_end... function it switches back to IRQ mode
(I have the old pc on sp_irq and some other things too)

>   4. A real interrupt/exception routine must finished with an "s-bit set" 
>     instruction. For an interrupt, it should be         subs    pc, lr, #4.This
>     "s-instruction" save automatically the cpsr to spsr_xx and restore theold
>     cpsr (before interrupt). I give you my my minimal asm interrupthandler that 
>     calls a pure C interrupt handler:
>     irqHandler: 
>     stmfd   sp!, {a1-a4,ip,lr}      /* Push the scratch, link & ip regs */
>  
>              mov     lr, pc   /* Save the return addr. intothe lr */
>              ldr     pc, interrupt_handler   /* Branch to the C interrupt
>                                          handler       */               
>              ldmfd   sp!, {a1-a4,ip,lr}  
>                      /* Pop the scratch, link & ip regs */              
>              subs    pc, lr, #4    

>    /* Exception return and restore cpsr       */ 

I do this manually. I have the return address on sp_irq. I can´t do 
ldmia	sp!, {......}^
This would directly lead to the program that was interrupeted. That´s why I copy
lr from the stack to a swap word at #40 and change to the previos mode (line
0x201ab34 and 0x201ab4c). I put this on the stack, make a call to os->schedule()
and restore it later.
Finally I just do
ldmia	sp!, {r0, r1, r2, r3, r12, lr, pc}
It is quite ugly, I know that but it works.


But: The bug remains the same! It still should cp r0 to cpsr at 0x201ab14!

I just compiled gdb with 
configure --target=$target --prefix=$prefix -v
make all install CFLAGS="-g -O0"
Worked fine.

Now I compile gdb a second time for my host and then I will see how gdb looks
like in gdb! ( I didn´t say "make distclean", hope it is working anyway)

Nice weekend to all,

Jens-Christian

P.S.:

This is the whole listing of the mentioned function (not much of interrest at
this point of time). It looks little ugly, but it works!


0x201ab04 <interrupt_end_os_schedule_0>:	ldmia	sp!, {r1, r2, r3, r12, lr}
0x201ab08 <interrupt_end_os_schedule_0+4>:	mrs	r0, CPSR
0x201ab0c <interrupt_end_os_schedule_0+8>:	bic	r0, r0, #31	; 0x1f
0x201ab10 <interrupt_end_os_schedule_0+12>:	orr	r0, r0, #146	; 0x92
0x201ab14 <interrupt_end_os_schedule_0+16>:	msr	CPSR_fc, r0
0x201ab18 <interrupt_end_os_schedule_0+20>:	ldr	r0, [pc, #1f8]	; 0x201ad18 <tc2_interrupt_handler__Fv+56>
0x201ab1c <interrupt_end_os_schedule_0+24>:	str	r0, [r0, #304]
0x201ab20 <interrupt_end_os_schedule_0+28>:	ldmia	sp!, {r0, lr}
0x201ab24 <interrupt_end_os_schedule_0+32>:	msr	SPSR_fc, lr
0x201ab28 <interrupt_end_os_schedule_0+36>:	stmdb	sp!, {r0, r1}
0x201ab2c <interrupt_end_os_schedule_0+40>:	ldr	r0, [sp, #8]
0x201ab30 <interrupt_end_os_schedule_0+44>:	mov	r1, #0	; 0x0
0x201ab34 <interrupt_end_os_schedule_0+48>:	str	r0, [r1, #40]
0x201ab38 <interrupt_end_os_schedule_0+52>:	ldmia	sp!, {r0, r1, lr}
0x201ab3c <interrupt_end_os_schedule_0+56>:	mrs	lr, SPSR
0x201ab40 <interrupt_end_os_schedule_0+60>:	msr	CPSR_fc, lr
0x201ab44 <interrupt_end_os_schedule_0+64>:	stmdb	sp!, {r0, r1, r2, r3, r12, lr, pc}
0x201ab48 <interrupt_end_os_schedule_0+68>:	mov	r3, #0	; 0x0
0x201ab4c <interrupt_end_os_schedule_0+72>:	ldr	r0, [r3, #40]
0x201ab50 <interrupt_end_os_schedule_0+76>:	stmdb	sp!, {r0}
0x201ab54 <interrupt_end_os_schedule_0+80>:	mrs	r0, CPSR
0x201ab58 <interrupt_end_os_schedule_0+84>:	stmdb	sp!, {r0}
0x201ab5c <interrupt_end_os_schedule_0+88>:	ldr	r3, [pc, #18]	; 0x201ab7c <interrupt_end_os_schedule_0+120>
0x201ab60 <interrupt_end_os_schedule_0+92>:	ldr	r0, [r3]
0x201ab64 <interrupt_end_os_schedule_0+96>:	bl	0x201871c <schedule__5Sched>
0x201ab68 <interrupt_end_os_schedule_0+100>:	ldmia	sp!, {r0}
0x201ab6c <interrupt_end_os_schedule_0+104>:	msr	CPSR_fc, r0
0x201ab70 <interrupt_end_os_schedule_0+108>:	ldmia	sp!, {r0}
0x201ab74 <interrupt_end_os_schedule_0+112>:	str	r0, [sp, #24]
0x201ab78 <interrupt_end_os_schedule_0+116>:	ldmia	sp!, {r0, r1, r2, r3, r12, lr, pc}


> I hope my remarks will help you. Have a good week-end.
> Pierre.
> 
> 
> 

----------------------------------------
Content-Type: text/html; name="unnamed"
Content-Transfer-Encoding: 7bit
Content-Description: 
----------------------------------------

-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: Re (2nd): a small bug in the arm simulator

[Jens-Christian Lache]

Hi everybody!

I have now compiled the gdb with target=arm-elf and a second gdb
with target i686-pc-linux-gnu. I can load the gdb-arm-elf binary 
load in gdb-arm-elf my program and step to the discussed function
"interrupt_end_os_schedule_0".

I would like to see where the commands

-	0x201aa90	<interrupt_end_os_schedule_0+16>:		msr	CPSR_fc, r0
gets interpreted. Any suggestions for a breakpoint?

jc


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

a small bug in the arm simulator

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

Hi! 

First of all: Thank you a lot for having fixed the "swi" instruction! No
more "unknown swi xxx". I have stepped through all the code from my
swi_wrapper and swi_handler and it worked very nice! :-) :-)

I think, I have found the little bug in the arm simulator.

It is only one line in "armsupp.c", function ARMul_FicCPSR:

void
ARMul_FixCPSR (ARMul_State * state, ARMword instr, ARMword rhs)
{
  state->Cpsr = ARMul_GetCPSR (state);
  /* original src */
  /* if (state->Bank != USERBANK) */                             // buggy
  /* end original src */
  /* altered src */
    if (state->Mode != USER32MODE)
  /* end altered src */
    {				/* In user mode, only write flags */
      if (BIT (16))
	SETPSR_C (state->Cpsr, rhs);
      if (BIT (17))
	SETPSR_X (state->Cpsr, rhs);
      if (BIT (18))
	SETPSR_S (state->Cpsr, rhs);
    }
  if (BIT (19))
    SETPSR_F (state->Cpsr, rhs);
  ARMul_CPSRAltered (state);
}

The original version tried to determine the cpu state by the banked 
registers. This works most time, but not if we are in system mode. System and 
user mode have same banked registers. That why 

msr cpsr, r0

worked for all modes but not for system mode.

I don´t know, how to care about the case we are in USER26MODE, it could be 
done with some "defines" I would suppose.

I hope this little fix does not have any side effects!

Regards,

Jens-Christian

-- 
Jens-Christian Lache
www.tu-harburg.de/~sejl1601
lache@tu-harburg.de
Tel.: 01759610756 (Hamburg)

Re: a small bug in the arm simulator

[Nick Clifton]

Hi Jens-Christian,

  Thanks for finding the bug and submitting the patch.  I have applied
  it to the sources.  In the future if you have other problems with
  the simulator, you might also like to copy the bug report to the
  binutils mailing list <binutils@sources.redhat.com>, which also has
  an interest in this tool.

Cheers
        Nick