This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
SVC SPSR overwritten in Arm HAL
- From: Pierre Habraken <Pierre dot Habraken at imag dot fr>
- To: ecos-patches at sources dot redhat dot com
- Date: Wed, 16 Apr 2003 08:39:34 +0200
- Subject: SVC SPSR overwritten in Arm HAL
- Organization: Université Joseph Fourier
Hello,
I recently noticed the following issue while I was debugging a Redboot
based Arm program using its own chained SWI handler:
- if the execution of the SWI handler is traced using step by step
execution, then the program crashes or hangs after the handler has
returned.
- if the SWI handler is run without being stepped in, then the program
behaves as expected (apart from the bug I was initially trying to track
down).
The reason why the program crashes or hangs is that after returning from
step by step execution of a SWI call the stack pointer and return
address of the main program have wrong values.
The origin of this misbehavior resides in the HAL exception handler
(vector.S): If an exception or IRQ occurs while the processor is running
in SVC mode, then the saved psr of the SVC mode (spsr_svc) is
overwritten by the exception handler at the time the latter prepares
itself to return:
=============================================================
return_from_exception:
ldr r0,[sp,#armreg_cpsr]
msr spsr,r0
^^^ ^^^^^^^
// return to supervisor mode is simple
and r1,r0,#CPSR_MODE_BITS
cmp r1,#CPSR_SUPERVISOR_MODE
ldmeqfd sp,{r0-r14,pc}^
...
=============================================================
The reported misbehavior is fixed by applying the change below to the
exception handler:
=============================================================
return_from_exception:
ldr r0,[sp,#armreg_cpsr]
// return to supervisor mode is simple
and r1,r0,#CPSR_MODE_BITS
cmp r1,#CPSR_SUPERVISOR_MODE
bne 1f
msr cpsr, r0
ldmfd sp, {r0-r14, pc}
1:
msr spsr, r0
...
=============================================================
Depending on the type of program or application, one can consider that
the original behavior is either a bug or a feature. So, taking in
account the fact that the fix I propose above adds one instruction (bne)
only to the execution flow, is it worth to create a cdl option for it ?
In case the inclusion of the fix is controlled by a cdl entry, should
the default behavior of the handler be the original one (spsr
overwritten) or the modified one (spsr preserved) ?
I'll wait for core maintainers advice and then send a full patch with
comments and changelog entry (and cdl entry if required).
Pierre
--
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre dot Habraken at imag dot fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________