From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens-Christian Lache <lache@tu-harburg.de>
To: "Pierre Saucourt-Harmel (r54698)" <pierre.saucourt-harmel@motorola.com>
Cc: gdb@sources.redhat.com
Subject: Re: Re (2nd): a small bug in the arm simulator
Date: Fri, 23 Feb 2001 09:32:00 -0000
Message-id: <0102231829090Q.28931@lab04>
References: <0102231647190K.28931@lab04> <3A9696DF.64AA0CA0@motorola.com>
X-SW-Source: 2001-02/msg00318.html

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